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Certification and Warranty 


Certification Hewlett-Packard Company certifies that this product met its 

published specifications at the time of shipment from the factory. 
Hewlett-Packard further certifies that its calibration measurements 
are traceable to the United States National Bureau of Standards, to 
the extent allowed by the Bureau’s calibration facility, and to the 
calibration facilities of other International Standards Organization 
members. 

Warranty This Hewlett-Packard system product is warranted against defects 
in materials and workmanship for a period of 90 days from date of 
installation. During the warranty period, HP will, at its option, 
either repair or replace products which prove to be defective. 

Warranty service of this product will be performed at Buyer’s 
facility at no charge within HP service travel areas. Outside HP 
service travel areas, warranty service will be performed at Buyer’s 
facility only upon HP’s prior agreement and Buyer shall pay HP’s 
round trip travel expenses. In all other cases, products must be 
returned to a service facility designated by HP. 

For products returned to HP for warranty service, Buyer shall 
prepay shipping charges to HP and HP shall pay shipping charges 
to return the product to Buyer. However, Buyer shall pay all 
shipping charges, duties, and taxes for products returned to HP 
from another country. HP warrants that its software and firmware 
designated by HP for use with an instrument will execute its 
programming instructions when properly installed on that 
instrument. HP does not warrant that the operation of the 
instrument, or software, or firmware will be uninterrupted or error 
free. 

Limitation of Warranty 

The foregoing warranty shall not apply to defects resulting from 
improper or inadequate maintenance by Buyer, Buyer-supplied 
software or interfacing, unauthorized modification or misuse, 
operation outside of the environment specifications for the 
product, or improper site preparation or maintenance. 



No other warranty is expressed or implied. HP specifically 
disclaims the implied warranties of merchantability and fitness for 
a particular purpose. 

Exclusive Remedies 

The remedies provided herein are buyer’s sole and exclusive 
remedies. HP shall not be liable for any direct, indirect, special, 
incidental, or consequential damages, whether based on contract, 
tort, or any other legal theory. 

Product maintenance agreements and other customer assistance 
agreements are available for Hewlett-Packard products. 




For any assistance, contact your nearest Hewlett-Packard Sales and 
Service Office. 



Notice 


Hewlett-Packard makes no warranty of any kind with regard to 
this material, including, but not limited to, the implied warranties 
of merchantability and fitness for a particular purpose. 

Hewlett-Packard shall not be liable for errors contained herein or 
for incidental or consequential damages in connection with the 
furnishing, performance, or use of this material. 

Hewlett-Packard assumes no responsibility for the use or reliability 
of its software on equipment that is not furnished by 
Hewlett-Packard. 

Copyright 1990 Hewlett-Packard Company. 

This document contains proprietary information, which is 
protected by copyright. All rights are reserved. No part of this 
document may be photocopied, reproduced or translated to 
another language without the prior written consent of 
Hewlett-Packard Company. The information contained in this 
document is subject to change without notice. 

HP and HP-UX are trademarks of Hewlett-Packard Company. 

UNIX is a registered trademark of AT&T. 

TORX is a registered trademark of Camcar Division of Textron, 
Inc. 

Hewlett-Packard Company 
Logic Systems Division 
8245 North Union Boulevard 
Colorado Springs, CO 80920, U.S.A. 



Printing History 


New editions are complete revisions of the manual. The date on 
the title page changes only when a new edition is published. 

A software code may be printed before the date; this indicates the 
version level of the software product at the time the manual was 
issued. Many product updates and fixes do not require manual 
changes, and manual corrections may be done without 
accompanying product changes. Therefore, do not expect a 
one-to-one correspondence between product updates and manual 
revisions. 
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Electromagnetic Interference 


What Is 

Electromagnetic 

Interference? 


All types of electronic equipment are potential sources of 
unintentional electromagnetic radiation which may cause 
interference with licensed communication services. Products which 
utilize digital waveforms such as any computing device are 
particularly characteristic of this phenomena and use of these 
products may require that special care be taken to ensure that 
Electromagnetic Interference (EMI) is controlled. Various 
government agencies regulate the levels of unintentional spurious 
radiation which may be generated by electronic equipment. The 
operator of this product should be familiar with the specific 
regulatory requirement in effect in his locality. 

The HP 64000-UX has been designed and tested to the 
requirements of the Federal Republic of Germany VDE 0871 
Level A. They have been licensed with the German ZZF as Level 
A products (FTZ C-l 12/82. These specifications and the laws of 
many other countries require that if emissions from these products 
cause harmfull interference with licensed radio communications, 
that the operator of the interference source may be required to 
cease operation of the product and correct the situation. 


Reducing the Risk 
Of EMI 


1. Ensure that the top cover of the HP 64120A 
Instrumentation Cardcage is properly installed and that all 
screws are tight (do not over tighten). 

2. When using a feature set which includes cables that egress 
from the chassis slot of the HP 64120A, insure that the 
knurled nuts and ferrels, or brackets that ground the cable 
shields are clean and tight (Do not overtighten). The 
EEPROM Programmer cable has an exposed shield that 
must make contact with the cable clamp. 

3. During times of infrequent use, disconnect the EEPROM 
Programmer and cables from the card cage and the target 
system. 

4. Use only shielded coaxial cables on the four external BNC 
connectors on the rear of the HP 64120A 

5. Use only the shielded IMB cable supplied with the 
HP 64120A for connection to additional HP 64120A 
Instrumentation Cardcages. 

6. Use only shielded cables on the IEEE 488 interface 
connector to the host computer. 



Reducing 

Interference 


In the unlikely event that emissions from the HP 64000-UX System 
result in electromagnetic interference with other equipment, you 
may use the following measures to reduce or eliminate the 
interference. 

1. If possible, increase the distance between the emulation 
system and the susceptible equipment. 

2. Rearrange the orientation of the chassis and cables of the 
emulation system. 

3. Plug the HP 64120A into a separate power outlet from the 
one used by the susceptible equipment (the two outlets 
should be on different electrical circuits). 

4. Plug the HP 64120A into a separate isolation transformer 
or power line filter. 

You may need to contact your local Hewlett-Packard sales 
office for additional suggestions. Also, the U.S.A. Federal 
Communications Commission has prepared a booklet 
entitled How to Identify and Resolve Radio - TV Interjerence 
Problems which may be helpful to you. This booklet (stock 
#004-000-00345-4) may be purchased from the 
Superintendent of Documents, U.S. Government Printing 
Office, Washington, D.C. 20402 U.S.A. 


Manufacturer’s Declarations 


U.S.A. Federal 
Communications 
Commission 


Federal Republic of 
Germany 


Warning - This equipment generates, uses, and can radiate radio 
frequency energy and if not installed and used in accordance with 
the instructions manual, may cause interference to radio 
communications. Operation of this equipment in a residential area 
is likely to cause interference in which case the user at his own 
expense will be required to take whatever measures may be 
required to correct the interference. 

Wenn Ihr Gerat in der Bundesrepublik Deutschland einschl. 
Westerlin betrieben wird, senden Sie bitte die beiliegende 
Postkarte ausgefullt an Ihr zustandiges Fernmeldeamt. 



Safety 





Summary Of Safe The following general safety precautions must be observed during 
Procedures a ll phases of operation, service, and repair of this instrument. 

Failure to comply with these precautions or with specific warnings 
elsewhere in this manual violates safety standards of design, 
manufacture, and intended use of the instrument. Hewlett-Packard 
Company assumes no liability for the customer’s failure to comply 
with these requirements. 

Ground The Instrument 

To minimize shock hazard, the instrument chassis and cabinet must 
be connected to an electrical ground. The instrument is equipped 
with a three-conductor ac power cable. The power cable must 
either be plugged into an approved three-contact electrical outlet 
or used with a three-contact to two-contact adapter with the 
grounding wire (green) firmly connected to an electrical ground 
(safety ground) at the power outlet. The power jack and mating 
plug of the power cable meet International Electrotechnical 
Commission (IEC) safety standards. 

Do Not Operate In An Explosive Atmosphere 

Do not operate the instrument in the presence of flammable gases 
or fumes. Operation of any electrical instrument in such an 
environment constitutes a definite safety hazard. 

Keep Away From Live Circuits 

Operating personnel must not remove instrument covers. 
Component replacement and internal adjustments must be made 
by qualified maintenance personnel. Do not replace components 
with the power cable connected. Under certain conditions, 
dangerous voltages may exist even with the power cable removed. 
To avoid injuries, always disconnect power and discharge circuits 
before touching them. 



Do Not Service Or Adjust Alone 


J 

Because of the danger of introducing additional hazards, do not 
install substitute parts or perform any unauthorized modification 
of the instrument. Return the instrument to a Hewlett-Packard 
Sales and Service Office for service and repair to ensure that safety 
features are maintained. 

Dangerous Procedure Warnings 

Warnings, such as the example below, precede potentially 
dangerous procedures throughout this manual. Instructions 
contained in the warnings must be followed. 


Do not attempt internal service or adjustment unless another 
person, capable of rendering first aid and resuscitation, is present. 

Do Not Substitute Parts Or Modify Instrument 


Warning 



Dangerous voltages, capable of causing death, are present 
in this instrument. Use extreme caution when handling, 
testing, and adjusting. 






Safety Symbols Used The following is a list of general definitions of safety symbols used 
In Manuals on equipment or in manuals: 



Instruction manual symbol: the product is marked with this symbol 
when it is necessary for the user to refer to the instruction manual 
in order to protect against damage to the instrument. 


h 


Indicates dangerous voltage (terminals fed from the interior by 
voltage exceeding 1000 volts must be marked with this symbol). 


OR 



Protective conductor terminal. For protection against electrical 
shock in case of a fault. Used with field wiring terminals to indicate 
the terminal which must be connected to ground before operating 
the equipment. 


Low-noise or noiseless, clean ground (earth) terminal. Used for a 
signal common, as well as providing protection against electrical 
shock in case of a fault. A terminal marked with this symbol must 
be connected to ground in the manner described in the installation 
(operating) manual before operating the equipment. 


rb 0B 


Frame or chassis terminal. A connection to the frame (chassis) of 
the equipment which normally includes all exposed metal 
structures. 


Alternating current (power line). 


Direct current (power line). 


Alternating or direct current (power line). 



Note 



The Note sign denotes important information. It calls your 
attention to a procedure, practice, condition, or similar situation 
which is essential to highlight. 



Caution 



The Caution sign denotes a hazard. It calls your attention to an 
operating procedure, practice, condition, or similar situation, 
which, if not correctly performed or adhered to, could result in 
damage to or destruction of part or all of the product. 


Warning 



The Warning sign denotes a hazard. It calls your attention to 
a procedure, practice, condition or the like, which, if not 
correctly performed, could result in injury or death to 
personnel. 



CONDUCTIVE FOAM OR PLASTIC OVER EMULATOR 
PINS MAY CAUSE ERRATIC OPERATION. 


The emulator user assembly pins are covered at the time of 
shipment with either a conductive foam wafer or a conductive 
plastic pin protector. This is done for two reasons: 

1) to protect the user interface circuitry within the emulator 
from electro-static discharge (ESD), 

2) to protect the delicate gold plated pins of the probe 
assembly from damage due to impact. 

Both the foam and plastic protection devices are conductive. This 
may cause erratic performance of the emulation or analysis system 
during operation, and also during option_test performance 
verification. Therefore, it is recommended that the foam or plastic 
device be removed before using the emulation or analysis system or 
before running option test performance verification. 

When not using the emulator, the foam or plastic assembly should 
be replaced to retain protection for the probe pins and protection 
from ESD. 
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HOW TO USE THIS MAP 

Tasks are listed down the left-hand side of the rows. Hardware 
and software are shown along the top of the columns. 
Row/column intersections show the manuals you need when 
performing the tasks using the hardware and_ software. 

EXAMPLE: All manuals needed to use an emulator are shown at 
the intersection of the USE row and EMUIATIO-N_ r column. Further, 
the emulation reference manual is in the same binder with the 
processor-specific manual for your emulator. 


KEY 

= Use the manual(s) pointed to by the arrow when 
performing the task (on the left) with the product 
(shown above). 

= Indicates manuals contained in same binder. 


0 


0 : 


Reference Manuals may need to be used. 


= Software Installation Manual includes information for 
the product shown above. 

/A = Your friendly, fast, efficient, reliable, 

M results-oriented HP Customer Support staff. 

★ 

A = Automated version for hardware and software 

system installation 

version Kit = Makes an existing HP 64100A or HP 64110A station 
into an HP 64000-UX supported package consisting 
of a terminal, cardcage, and flexible disc drives 
(if drives were part of the original product). 

]| Package 

Operation = Shows you how to operate the parts of 

your converted HP 64100A or HP 64110A station. 
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USING THIS MANUAL 


Organization 

Chapter 1 Introducing The 68030 Emulator contains a brief description of 
the 68030 emulator. 

Chapter 2 Installing Emulation Hardware contains information on installing 
your 68030 emulation system hardware into the instrumentation 
cardcage and making a measurement system. This chapter also 
contains information on connecting the emulator to your target 
system. 

Chapter 3 Getting Started steps you through the emulation process from 

creating an example program to performing measurements on the 
execution of that program in emulation. 

The Getting Started chapter discusses preparing your program 
modules and the files that are generated by assembling, compiling, 
and linking programs. See the appropriate cross assembler/linker 
and compiler manuals for more detailed information on preparing 
program modules for emulation. 

Chapter 4 Configuring Your Emulator shows how to access the emulation 
configuration questions, describes the options available when 
configuring the emulator, and shows how to load configuration 
command files from a previous emulation session. 

Chapter 5 DeMMUer - What It Is And How It Works describes what the 
deMMUer is, how the deMMUer operates, when to use the 
deMMUer, and the restrictions you need to observe when using the 
deMMUer. 


Chapter 6 


Chapter 7 


Chapter 8 


Chapter 9 


Chapter 10 


Appendix A 


Appendix B 


Appendix C 


Target System Interface provides information about the 68030 pins 
and how the emulator interacts with those pins. It also provides 
guidelines for using the emulator with a target system and provides 
information you need to know about how the emulator interacts 
with your target system. 


The Emulation Monitor Program provides a detailed description 
of the emulation monitor program and how to modify it for your 
system requirements. 


Using Custom Coprocessors describes how to make a custom 
coprocessor register format file and how to modify the emulation 
monitor so that your emulation system can display and modify 
coprocessor registers. 

Using Simulated I/O And Simulated Interrupts describes how to 
set up your emulator to use host I/O resources to simulated target 
system I/O and how to use the simulated interrupt features of the 
emulator. 

How The Emulator Works provides a detailed description of how 
many of the emulator features work. Understanding how the 
emulator works helps you use the emulator more effectively and 
helps you resolve problems you may encounter. 


Emulation Error Messages contains descriptions of the most 
serious error messages you may encounter and information on how 
to correct the errors. 

Demonstration Source Files provides listings of the demonstration 
programs used in this manual as a reference for you when working 
through the examples. 


Timing Comparisons lists timing comparisons between 68030 
processors and the HP 64430 Emulator. It also provides the DC 
electrical specifications for the HP 64430 Emulator. 



Understanding The Examples 


C 






This manual assumes that you are using the User-Friendly 
Interface Software (HP 64808S) which is activated by executing the 
HP 64000-UX pmon command. This means that the manual will 
show you how to enter HP 64000-UX system commands (edit, 
compile, assemble, link, msinit, msconfig, etc.) by telling you to 
press various softkeys. 

If you are not using "pmon", you will find the User 
Interface/HP-UX Cross Reference appendix of the 68030 
Emulation Reference Manual especially useful. The cross reference 
table shows you how the "pmon” softkeys translate into commands 
that can be entered from the HP-UX prompt. 

The examples provided throughout this manual use the following 
structure: 

PRESS edit module.S 

PRESS means you should enter a command by selecting the 
or press softkeys and/or typing in any file names or other 
variables which are not provided in the softkey 
selections. 

edit softkeys will appear in bold type. Usually you will not 

be prompted to use the —ETC— softkey to search for 
the appropriate softkey template. Three softkey 
templates are available at the HP 64000 system 
monitor level. 

module.S this is the name of a file which you must type in. 

Softkeys are not provided for this type of selection 
since it is variable. However, a softkey prompt such as 
<FILE> will appear as a softkey selection. 

For most commands, you must press the Return (or Enter) key 
before the command is actually executed. 



Notes 
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Introducing The 68030 Emulator 


Overview This chapter provides the following information: 

■ Safety considerations for your emulator 

■ Purpose of the 68030 emulator 

■ Features of the 68030 emulator 

■ What information is given in this manual 


Safety 

Considerations 


The HP 64000-UX Microprocessor Development Environment, 
along with the HP 64430 Emulation Subsystem, is a Class 1 
instrument (provided with a protective earth terminal) and meets 
safety standard IEC 348, "Safety Requirements for Electronic 
Measuring Apparatus”. This Class I instrument meets 
Hewlett-Packard Safety Class I and has been shipped in a safe 
condition. Review both the instrument and the manual for safety 
markings and instructions before operation. Read and become 
familiar with the "Safety Summary", which follows the 
Certification/Warranty page of this manual, in addition to the 
items listed in chapter 2. 
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Purpose of the 
68030 Emulator 


Emulator Features 
Software Debugging 

Symbols 

Real-Time Operation 


The 68030 emulator is designed to replace the 68030 
microprocessor in your target system so you can control operation 
of the microprocessor in your application hardware (usually 
referred to as the target system). The 68030 emulator performs just 
like the 68030 microprocessor, but is a device that allows you to 
control the 68030 directly. 


The HP 64430 Real-Time Emulator for 68030 microprocessors is a 
powrful tool for both software and hardware designers. Using the 
HP 64430 Emulator’s emulation memory (up to 2Mega bytes), 
software debugging can be done without functional target system 
memory. 

Symbolic debugging lets you debug programs using the same 
symbols that you defined in your source code. You can control 
program flow using software breakpoints, single-stepping by 
opcode, and run-from and run-until commands. 


Real-time signifies continuous execution of your program at full 
rated processor speed without interference from the emulator. 
(Such interference occurs when the emulator needs to break to the 
monitor to perform an action you requested, such as displaying 
target system memory.) 

Emulator features performed in real time include: running and 
analyzer tracing. 

Emulator features not performed in real time include: display or 
modify of target system memory; load/dump of target memory, and 
display or modification of registers. 
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Clock Speed 


Emulation Memory 


Analysis 


Measurements can be made using the emulator’s internal 20 MHz 
clock or an external clock from 20 to 33.33 MHz with no wait states 
added to target memory. 

Memory mapping during an emulation configuration session maps 
physical memory only. If the MMU is enabled, the user is 
responsible for knowing user physical memory usage. 

Dual-ported memory allows you to display or modify physical 
emulation memory without halting the processor. 

Flexible memory mapping lets you define address ranges over the 
entire 4 Gbyte address range of the 68030. You can reference 
emulation memory or target system memory in 256-byte blocks. 
Blocks can be defined as (1) emulation; RAM or ROM, 
interlocked, synchronous, asynchronous with a data port width of 
8-bits, 16-bits or 32-bits (2) target; RAM or ROM, bus error 
N blocked, cache disabled, burst mode blocked, or (3) guarded access. 
(Refer to the "Answering Emulation Configuration Questions" 
chapter for information on memory mapping.) 

The 68030 emulator will attempt to break to the emulation 
monitor upon accessing guarded memory; additionally, you can 
configure the emulator to break to the emulation monitor upon 
performing a write to ROM (which will stop a runaway program). 


The integrated emulation bus analyzer provides real-time analysis 
of all bus-cycle activity. You can define break conditions based on 
address and data bus cycle activity. In addition to hardware break, 
software breakpoints can be used for execution breakpoints. You 
can select any one of the eight 68030 software breakpoint 
instructions to be used by the emulator. 

When the MMU is enabled, analysis data is physical addresses only, 
with no symbols. When the deMMUer is enabled, the analyzer can 
see logical addresses and can display symbols. 

Analysis functions include trigger, storage, count, and context 
directives. The analyzer can capture up to 2047 events, including all 
address, data, and status lines. 

Commands for the HP 64430 emulator and HP 64404A and 
HP 64405A integrated analyzers have been integrated into one 
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Registers 

Single-Step 

Breakpoints 

Reset Support 
Memory Management 


softkey package, making it easy to make both emulation and 
analysis measurements. 

You can display or modify the 68030 internal CPU register 
contents. This includes the ability to modify the program counter 
(PC) value so you can control where the emulator starts a program 
run. You can also display or modify the 68030 MMU register 
contents. 


You can direct the emulation processor to execute a single 
instruction or a specified number of instructions. (If a foreground 
monitor is selected, the target system trace vector must point to 
MONITOR_ENTRY in the foreground monitor code for single 
step to function properly). Refer to the ’’Single Stepping with 
Foreground Monitor’’ and ’’Single Stepping with Background 
Monitor” paragraphs in chapter 10 for further information.) 

You can set the emulator/analyzer interaction so the emulator will 
break to the monitor program when the analyzer finds a specific 
state or states, allowing you to perform post-mortem analysis of the 
program execution. You can also set software breakpoints in your 
program. With the 68030 emulator, setting a software breakpoint 
inserts a 68030 BKPT instruction into your program at the desired 
location. 


The emulator can be reset from the emulation system under your 
control; or your target system can reset the emulation processor. 


Memory can be accessed either logically or physically, depending 
on whether the emulator deMMUer is configured to be active or 
inactive. The on-chip Memory Management Unit (MMU) of the 
68030 translates logical (virtual) addresses to physical addresses 
that are placed on the processor address bus. The deMMUer 
hardware filters the physical address bus to the analyzer. When the 
deMMUer is disabled, it passes the data through unchanged 
(physical). Symbols, which are in logical memory, are not 
meaningful when the deMMUer is disabled. If the deMMUer is 
configured with MMU information and some ranges of interest, it 
can track table walks. Tracking the table walks allows the 
deMMUer to maintain a cache of physical to logical translations. 
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By filtering the physical trace data and substituting logical 
addresses, the analyzer can then show this logical data with symbols. 


Custom 

Coprocessors 

Support 


Function Codes 


Foreground or 
Background 
Emulation Monitor 


The 68030 emulator does not contain an on-board floating point 
processor and does not provide support for custom coprocessors in 
the background monitor mode. It does, however, support custom 
coprocessors when operating in the foreground monitor mode. In 
foreground monitor mode, the custom coprocessor instructions 
can be disassembled in trace displays. You can also display and 
modify the custom coprocessor registers. 

The HP 64430 emulator supports the use of 68030 function codes. 
Emulation memory can be mapped to any of the functional address 
spaces (CPU, supervisor or user, program or data, or undefined). 
Function codes can be used as an additional specification when 
referencing memory. 

The 68030 emulator is supplied with both a foreground and a 
background monitor. This allows you to trade off between: 


■ Not using the target system resources but having full 
logical/physical support with the background monitor. 

■ Having full interrupt handling and custom coprocessor 
support with the foreground monitor. 


The emulation monitor is a program that is executed by the 
emulation processor. It allows the emulation controller to access 
target system resources. For example, when you display target 
system memory, it is the monitor program that executes 68030 
instructions which read the target memory locations and send their 
contents to the emulation controller. 

The monitor program can execute in preground , the mode in which 
the emulator operates as would the target processor. The 
foreground monitor occupies processor address space and executes 
as if it were part of the target program. 


Introduction 1-5 



Out-of-Circuit or 
In-Circuit Emulation 


Manual Coverage 


The monitor program can also execute in background , the emulator 
mode in which foreground operation is suspended so that 
emulation processor can be used to access target system resources. 
The background monitor does not occupy processor address space. 

The HP 64430 emulator can be used for both out-of-circuit 
emulation and in-circuit emulation. The emulation can be used in 
multiple emulation systems using other HP 64000-UX 
Microprocessor Development Environment emulators. 


This manual provides detailed information on operating the 
HP 64430 emulator for the 68030 processor. The information in 
this manual gives 68030 processor specific information. The 68030 
Emulation Reference Manual provides additional information 
about using 32-bit emulation, including detailed syntactical 
descriptions of the emulation commands. Detailed operating 
information for the HP 64404 and HP 64405 integrated analyzers is 
given in the Analysis Reference Manualfor 32-Bit Microprocessors 
and the 68030 Analysis Specfics manual. 
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Installing Your Emulator 


Overview This chapter: 

■ Reviews the safety considerations for installation. 

■ Provides preinstallation inspection instructions. 

■ Shows you how to configure boards in the HP 64120A 
Instrumentation Cardcage. 

■ Shows you how to install the emulation system hardware. 

■ Shows you how to connect the emulation probe cable to 
your target system. 

■ Shows you how to turn on the HP 64120A 
Instrumentation Cardcage. 


Introduction If you are installing your HP 64000-UX components as a new 

installation, refer to the HP 64000-UX Installation and 
Configuration Manual for instructions concerning the installation 
of the HP 64120A Instrumentation Cardcage. Also, refer to the 
preinstallation instructions given in this section. After you have 
done these, install the emulation system as instructed later in this 
section. 

Figure 2-1 identifies some key features of the HP 64120A 
Instrumentation Cardcage. The identifying labels used in this 
figure are used throughout this manual. Note the location of the 
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power switch. For more information on the hardware 
configuration, refer to the Installation and Corfiguration Manual. 



SELF TESTS PASSED 
INDICATORS 


POWER ON INDICATOR 




EXTERNAL LOAD ADDRESS HP-IB CONNECTOR 

IMB EXTENDER SWITCHES AND XFT 

CONNECTOR SWITCHES 


POWER SWITCH 


POWER CONNECTOR 
FUSE 


VOLTAGE SELECT 




Figure 2-1. Instrumentation Cardcage Features 
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Safety 

Considerations 


The HP 64000-UX Microprocessor Development Environment 
along with the HP 64430 Emulation System is a Class 1 instrument 
(provided with a protective earth terminal) and meets safety 
standard IEC 348, "Safety Requirements for Electronic Measuring 
Apparatus". This Class I instrument also meets Hewlett-Packard 
Safety Class I requirements and has been shipped in a safe 
condition. 


The user should review both the instrument and manual for safety 
markings and instructions before operation. Read and become 
familiar with the "Safety Summary", printed following the 
Certification/Warranty page of this manual, and the additional 
items listed below. 


Warning 




SHOCK HAZARD! DO NOT ATTEMPT TO DISRUPT 
PROTECTIVE GROUND! 

Any interruption of the power cord protective conductor 
(third prong of power cord plug) inside or outside the 
HP 64120A Instrumentation Cardcage or disconnection of 
the protective earth terminal in the power source (wall 
outlet) is likely to make the HP 64000-UX Microprocessor 
Development Environment DANGEROUS! Intentional 
interruption of the power cord protective conductor is 
prohibited. 


Warning 



SHOCK HAZARD! ONLY QUALIFIED PERSONNEL SHOULD 
SERVICE. 

Any adjustment, maintenance, or repair of the opened 
instrument must ONLY be carried out by QUALIFIED 
PERSONNEL aware of the HAZARDS involved. 
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Warnina ft shock hazard! do not use if safety features 
V HAVE BEEN IMPAIRED. 

If the safety features of the instrument have been damaged 
or defeated, the instrument shall not be used until repairs 
are made which restore the safety features. The safety 
features of the instrument could be disabled in the following 
instances: 

1. The instrument shows visible damage. 

2. The instrument falls to perform correct measurements. 

3. The instrument has been shipped or stored under 
unfavorable environmental conditions. Refer to the Service 
Supplement portion of this manual for information on the 
environmental specifications of storage and shipment. 


Preinstallation 

Inspection 


Unpack all of the emulation system circuit boards, cables, pod, and 
related equipment. Carefully inspect the equipment for damage 
that may ha\e occurred during shipping. If any damage is found, 
please contact your nearest Hewlett-Packard Sales/Service Office 
as soon as possible. 

Verify that all of the items that you ordered have been shipped. If 
any equipment is missing, please contact your nearest 
Hewlett-Packard Sales/Service Office as soon as possible. 
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Installing Your 
Emulation System 
Hardware 


This section tells you how to install your emulation hardware into 
the HP 64120A Instrumentation Cardcage. 


Warning |Q shock hazard! installation should only be 

V PERFORMED BY QUALIFIED PERSONNEL 

Any installation, servicing, adjustment, maintenance, or 
repair of this product must be performed only by qualified 
personnel. Make sure power is off prior to performing any of 
the installation instructions given below. 


Installation Proceed as follows to install the Emulation System and related 

Instructions equipment: 


Warning 



SHOCK HAZARD! HAVE YOU READ THE SAFETY 
SUMMARY? 

Read the safety summary at the front of this manual before 
installation or removal of the Emulation Subsystem. 


Caution 



DAMAGE TO CARDS AND CAGE! 

Power to the HP 64120A Instrumentation Cardcage must be 
removed before installation or removal of option cards (emulation, 
etc.) to avoid damage to the option cards and the development 
environment. 
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Turn Off Power 


Turn OFF power to the HP 64120A Instrumentation Cardcage 
(see figure 2-1 for the location of the power switch on the 
HP 64120A Instrumentation Cardcage). 

Remove The Card Cage Cover 

The HP 64120A Instrumentation Cardcage access cover is held in 
place by four screws on the top of the instrumentation cardcage as 
seen in figure 2-2. Loosen the four screws, and remove the access 
cover. 


ACCESS SCREWS 



Figure 2-2. Removing the Cardcage Access Cover 



Connect The Emulator Pod Cables To The Emulator Boards 

There are six cables from the emulation pod that must be 
connected to various cards in the card cage. Connect these cables 
as follows: 

1. Connect the two 44-conductor cables from the pod to the 
Emulator Control Board (HP 64430-66512). There are no 
color dots to follow because it does not matter which of 
the 44-conductor cables are connected to each of the 
44-pin connectors. 

2. Connect the 50-conductor cable from the pod to the 
Emulator Control Board (HP 64430-66512). 

3. If you are not using the DeMMUer board, connect the 
three 64-conductor cables from the pod to the Analysis 
Bus Generator (ABG) board (HP 64411-66503) following 
the yellow, red, and brown color dots for proper 
connections. 

4. If you are using the DeMMUer board, connect the three 
64-conductor cables from the pod to the DeMMUer board 
(HP 64431-66501) following the yellow, red, and brown 
color dots for proper connections. 

The pod cables connected to the ABG board (64411A) or the 
DeMMUer board (64431A) are protected by a plastic cover. After 
connecting the three 64 position cables to the applicable board, 
secure the plastic cable cover to the board by connecting four 
screws as shown in figure 2-3. Use a Torx TX 6 screwdriver. 
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Figure 2-3. ABG Protective Plastic Cable Cover 


Caution 



Install Boards Into The Card Cage 

Installation of the circuit boards is accomplished by sliding each 
circuit board into the circuit board guide slots. As you face the 
front of the HP 64120A Instrumentation Cardcage, the component 
side of the boards should face the right side of the instrumentation 
cardcage. Align the connector at the bottom of the board with the 
motherboard connector at the bottom of the card cage, then apply 
a downward pressure until the board is seated in the motherboard 
connector. Be sure the ejector handles are in their full horizontal 
position when the board has reached its full downward travel. 



POSSIBLE CABLE DAMAGE! Be careful to avoid scraping the 
cables or individual wires with the backs of the printed circuit 
boards. This will strip insulation from the cables and cause short 
circuits. 
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Four adjacent card cage slots are required for the circuit boards. 

Install the boards as follows: 

1. Install the boards in the card cage in the order shown in 
figure 2-4. 

2. Install the Interconnect Board across the three analysis 
boards as shown in figure 2-4. 

3. Install the power bus cable between the top left edges of 
the deMMUer board or the analysis bus generator and the 
emulator control board. This bus is not essential, but will 
improve reliability of the emulator/analyzer system. 


INTERCONNECT BOARD 


64405 
ANALYZER/EXPANDER 


64404 
ANALYZER BOARD 



INTERMODULE 
BUS (IMB) CABLE 


6441 1 
ANALYSIS BUS 
GENERATOR BOARD 
OR 64431 
DEMMUER BOARD 


POWER BUS 
CABLE 


64430 


HP 64120A ICC 
FRONT 


EMULATOR CONTROL 
BOARD 


Figure 2-4. Board Installation Into Cardcage 
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Secure The Pod Cables 


Each pod cable has a metal ferrule for strain relief. Snap the 
ferrule into one of the cable clamps on the instrumentation 
cardcage. If your instrumentation cardcage does not have cable 
clamps, you can order them from Hewlett-Packard Co. 

Reinstall Card Cage Access Cover 

Reinstall the card cage access cover and secure in place with the 
hold-down screws. 


Installing The 
Emulation Probe 
Into The Target 
System 


Caution 



POSSIBLE DAMAGE TO EMULATION PROBE! 

PROTECT AGAINST STATIC DISCHARGE! The emulation 
probe contains devices that are susceptible to damage by static 
discharge. Therefore, precautionary measures should be taken 
before handling the microprocessor connector attached to the end 
of the cable from the emulation probe to avoid damaging the 
internal components of the probe by static electricity. 
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Caution 

C 

Caution 

C 


Caution 

C 



POSSIBLE DAMAGE TO EMULATION POD! Do not install the 
emulation probe into the processor socket with power applied to 
the target system. The pod may be damaged if power is not 
removed before installation. 

When installing the emulation probe, be sure the probe is inserted 
into the processor socket so that pin A1 of the emulation probe 
aligns with pin A1 end of the processor socket. Damage to the 
emulation equipment may result if the probe is incorrectly installed. 



POSSIBLE DAMAGE TO TARGET SYSTEM! 

PROTECT YOUR CMOS TARGET SYSTEM COMPONENTS! If 
your system includes any CMOS components-turn on the 
HP 64120A Instrumentation Cardcage first, then turn on the target 
system; likewise, turn off the target system first, then the 
development environment. 


The emulation probe is provided with a pin protector that prevents 
damage to the probe when not in use (see figure 2-4). DO NOT 
use the probe without a pin protector installed. If the emulation 
probe is being installed on a densely loaded circuit board, there 
may not be enough room to accommodate the size of the probe. If 
this occurs, another pin protector may be stacked onto the existing 
pin protector. 

To install the microprocessor connector in a target system with a 
Pin Grid Array (PGA) socket (see figure 2-5), proceed as follows: 



POSSIBLE DAMAGE TO PGA PINS ! 

PROTECT PGA PINS FROM DAMAGE! To avoid damaging the 
PGA (Pin Grid Array) probe connector pins, use an 
insertion/extraction tool (such as Augat P/N TX 8136-13) for 
removing the PGA probe connector. 
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Figure 2-5. Installing Emulation Probe Into PGA Socket 


1. Remove the 68030 processor from the target system 
processor PGA socket. 

2. Store the 68030 processor in a protected environment. 
Note the location of pin A1 on both the microprocessor 
connector and the target system socket. 

3. Install the active probe into the target system processor 
socket. 


s J 
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Install Software 


Refer to the Installation Notice that you received with your 
HP 64000-UX media for complete software installation 
instructions. 


Installing 68030 
Emulation 
Software Updates 


After installing a new copy of the 68030 Emulation Software on a 
system, cycle the power off and then back on for all cardcages 
containing 68030 emulators. This updates and initializes all 
emulation software data structures. Run msinit before you run 
your next emulation session. Refer to chapter 3 for a description 
of msinit. 

When installing a different revision of the 68030.emulator 
software, delete all existing ".EB" emulation configuration files. 
Emulation configuration file names are suffixed by ".EA" and 
".EB". The ".EA" file is created when you end out of a "modify 
configuration" session after giving the configuration a filename. It 
is an editable file that you can use to modify your configuration 
without going through the "modify configuration" process during 
an emulation session. If you do modify it, delete the existing ".EB" 
file. The ".EB" file is created from an original ".EA" file. It 
becomes the executable file that the emulation software looks for 
when you load your emulation configuration file. For this reason 
you need to delete this file after updating your emulation software, 
since the new software may have changed something that is in the 
old ".EB" file. If there is no ".EB" file, the emulation software will 
use the ".EA" file to build a new one. You need not do anything 
with the ".EA" file. Questions that are answered in that file but are 
no longer in the configuration questions are ignored. New 
questions added to the configuration that are not answered in the 
".EA" file are assigned the default answer in the created ".EB” file. 
You may want to go through the "modify configuration" process 
and answer all the questions to make sure that your ".EA" file is 
current after you update your emulation software. 
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Turning On The 
HP 64120A 


The power switch for the HP 64120A Instrumentation Cardcage is 
identified in figure 2-1. 


Caution 



POSSIBLE DAMAGE TO TARGET SYSTEM! 

PROTECT YOUR CMOS TARGET SYSTEM COMPONENTS! 

If your system includes any CMOS components-turn on the 
HP 64120A Instrumentation Cardcage first, then turn on the target 
system; likewise, turn off the target system first, then the 
development environment. 


Turn the cardcage power on. Three green LED’s are visible from 
the front of the cardcage as seen in figure 2-1. All three should be 
illuminated to indicate proper operation of the development 
environment. If all three LED’s do not light up, refer to the 
HP 64120A Instrumentation Cardcage Service Manual for 
information on correcting any problems. 


2-14 Installation 



3 


Getting Started 


Overview 


Introduction 


This chapter describes how to do the following tasks: 

■ Create a subdirectory in which you can store your 68030 
related files. 

■ Initialize and define a measurement system. 

■ Assemble, compile, and link the emulation monitor and 
demonstration programs by using a makefile. 

■ Access the emulation system from the monitor level 
softkeys. 

■ Modify the default emulation configuration and map 
memory by loading a configuration file. 

■ Run an emulation session. 


This chapter gives an operational overview of the emulation 
process. The chapter leads you step-by-step through the tasks you 
must do to prepare your system for emulation and leads you 
through an emulation session. Emulation features are not 
explained in depth in this chapter. Its purpose is to familiarize you 
with the emulation process. Read the entire chapter and go 
through all exercises in the order presented. This will give you an 
understanding of the basic operation of the emulator. 
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Emulation System 
Used For 
Examples 


The examples given in this chapter (and throughout this manual) 
were developed with an emulation system including the 
components listed below. 


■ HP 64430SX Emulation System (includes Analyzer) 

■ HP 64874 Cross Assembler/Linker for MC68030 

■ HP 64907 68030 C Cross Compiler 


Making A 
Subdirectory For 
Your 68030 Project 


Before you start a new project, make a subdirectory for the project. 
This enables you to keep your files for each project separate from 
other files. Follow the rules listed below when you make your 
subdirectory. 


H Give the subdirectory a name consisting of from one to 
fourteen characters. If more than fourteen characters are 
used, all characters after the fourteenth character are 
truncated. 

H Any characters may be used in the name. Avoid conflict 
with special characters used in the HP-UX system software 
by restricting your subdirectory names to alphanumeric 
characters and the underscore (_) character. 

B Upper and lower case alphabetic characters are significant, 
i.e., ’’FILENAME" is a different name than "filename". 
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Note 



The path /usr/hp64000/bin must be added to the PATH parameter 
in your ".profile" file in order to execute HP 64000-UX commands 
as given in the examples in this manual. Otherwise, you must type 
the entire path name for HP 64000-UX commands, e.g., 

/usr/hp64000/bin/pmon instead of pmon. 


Do the following steps to make a subdirectory for your 68030 
project: 

1. Log in to the system using your login and password. 

2. Enter pmon Return. This accesses the HP 64000-UX 
system monitor. The HP 64000-UX system monitor is 
softkey driven. You should see softkey labels displayed on 
your screen. 

3. Press the —ETC— softkey repetitively until the makedir 
softkey appears as an option on the softkey label line. 

4. Press the makedir softkey and type in the name you wish to 
use for your directory (the name em68030 is used 
throughout this manual). Press the Return key on the 
keyboard. 

makedir em68030 Return 

You now have a subdirectory named em68030. 

Whenever you log in to your system to work on the 68030 project, 
you should change to this directory (using the chng_dir softkey). If 
you do most of your work on the 68030 project, you can modify 
your ".profile" file to change to this directory whenever you log in. 

If the permissions are set so that you can alter your own ".profile" 
file, add the line "cd SHOME/em68030" to your ".profile" file. You 
will then be in the new subdirectory each time that you log in. If the 
permissions are set so that you cannot modify your ".profile” file, 
see your HP-UX system administrator. The examples in this 
manual use the chng_dir command to change directories. 
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Initializing And 
Configuring Your 
Measurement 
System 


Note H If you have already initialized the instrumentation cardcage and 
w defined your measurement system, skip this section and go to the 
next section titled "Preparing Your Program Modules". 

Refer to the Measurement System manual for the HP 64000-UX 
Microprocessor Development Environment for detailed 
information on initializing and configuring measurement systems. 
The following procedure gives you a brief overview of the 
initialization and configuration process. 


To initialize your HP 64120A Instrumentation Cardcage and 
configure your 68030 emulation system, do the following steps: 

1. Press MEAS_SYS. 


Note 


The MEAS_SYSsoftkey is displayed after you enter the 
HP 64000-UX system monitor by executing the pmon command. 


You are now in the measurement_system application. The 
softkeys displayed at this level enable you to initialize and 
configure your measurement system. 

2. Press msinit Return. 

If you have only one system in your instrumentation 
cardcage, the softkey label line will disappear and the 
message "Working" will appear on the STATUS line. After 
a few seconds, the message "Hit return to continue" will 
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appear under the STATUS line. Press Return. The 
message will disappear and the softkey labels will return. 

If you have more than one system in your instrumentation 
cardcage, the softkey label line will disappear and the 
message "Working" will appear on the STATUS line. After 
a short time, a list of boards in the card cage may be 
displayed on the screen. Messages may appear on screen 
asking you to identify the boards in the different systems. 
After you have identified any boards requested by the 
system, the message "Hit return to continue" will appear 
under the STATUS line. Press Return. The message will 
disappear and the softkey labels will return. 

3. Press msconfig Return. 

The screen now displays the module(s) available to be 
assigned (top of the screen) to a measurement system 
(middle of the screen). 

4. Enter make_sys emul683k Return. 

5. Press add. If your 68030 emulator is the only system in the 
instrumentation cardcage, it will be assigned as module 0 
as shown at the top of the display. If more than one system 
is installed in the instrumentation cardcage, the 68030 
system module number may be different from 0. Identify 
the module number of the 68030 emulator shown at the 
top of the display and type it in from the keyboard. Press 
name_it, type in em68030 from the keyboard, and press 
Return. The command line will appear as follows: 

add 0 namingit em68030 

6. Press end Return. 

This command causes the system to exit the measurement 
configuration mode and return to the measurement system 
level. 
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7. Press -GOBACK- to exit the measurement system level and 
return to the HP 64000-UX system monitor. 

The 68030 Emulation module is now defined as module em68030 
in the measurement system (shown in the center of the screen). 


Preparing Your 
Program Modules 


Program modules must be assembled or compiled and then linked 
to create an absolute file. The emulator must be configured with a 
memory map that allocates memory to the addresses used during 
execution of the absolute file. Then the absolute file can be loaded 
into the emulator. 

Memory mapping is done for the demonstration programs in this 
chapter by loading a configuration file supplied with your 
demonstration software. Memory mapping is described in Chapter 
4. The assembly and compile procedures are not described in this 
manual. Refer to your assembler/linker/librarian and compiler 
manuals for detailed instructions on these processes. 

The next two subparagraphs obtain an absolute file to use for 
running the getting started procedure. If you have the HP 64874 
68030 Assembler/Linker and the HP 64907 68030 C Cross 
Compiler, create the absolute file by following instructions in the 
paragraph titled, "Creating The Absolute File In Your Own 
Subdirectory". 

If your system does not have the Assembler/Linker and C Cross 
Compiler specified above, you can still perform the demonstration 
emulation procedures in this manual. Follow the instructions in 
the paragraph titled, "Using The Absolute File In The Demo 
Directory. A complete absolute file is provided on the media with 
your emulation software. 

Whether you create the absolute file in your own subdirectory or 
use the absolute file in the demo directory, the absolute file is 
composed of the following source program modules: 


simint.c Simulated interrupt routines for the 

demonstration program. 
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towers.c 


The demonstration program. This program 
solves the popular "Towers of Hanoi" brain 
teaser puzzle. The program demonstrates 
many features of the emulator, including 
simulated I/O and simulated interrupts. 

entry.s and os.s These two programs together set up a virtual 
system by mapping the 68030 MMU. 

Listings of the simint.c and towers.c demonstration programs are 
included in appendix B of this manual. 


Note 



The README file in the demo directory contains more 
information about the demonstration files and their use. To read 
the README file, enter the following command: 


! more /usr/hp64000/demo/emul32/hp64430/README 


Creating The The demonstration programs used in this manual are provided on 
Absolute File In Your the media shipped with your 68030 emulation system in directory 
Own Subdirectory /usr/hp64000/demo/emul32/hp64430. Copy these programs to your 
y subdirectory by using the following command: 

copy /usr/hp64000/demo/emul32/hp64430/* em68030 Return 

Now enter your subdirectory by using the following command: 

cd em68030 Return 

A makefile has been included in the demonstration directory. Use 
the following commands to have the makefile create the absolute 
file for the getting started procedure: 

make clean Return 

Your display will show files being removed from your directory. 
These files were built to support the absolute file when it was 
resident in the demonstration directory. 
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Using The Absolute 
File In The Demo 
Directory 


Preparing The 
Emulation System 


Now create a complete absolute set of files in your own directory 
by entering the following command: 

make Return 

During execution of the make file, you will see two "Warning" 
messages appear on screen. These messages refer to symbols and a 
variable in the spmt_demo.c source file. Both of these Warning 
messages are normal. They involve a source file that won’t be used 
during the getting started procedures in this manual. 

Now go to the paragraph titled "Preparing The Emulation System". 

Follow this paragraph if your system does not have the HP 
compiler and linker needed to create the absolute file for the 
getting started procedure. An absolute file is supplied in directory 
/usr/hp64000/demo/emul32/hp64430. To run this absolute file, you 
must change to that directory. To change directories, press the 
chng_dir softkey and enter the directory pathname 
/usr/hp64000/demo/emul32/hp64430. The command line should 
appear as follows: 

cd /usr/hp64000/demo/emul32/hp64430 

Press the Return key. You should now be in the 68030 demo 
subdirectory. You can verify this by executing the HP-UX pwd 
(present working directory) command. 


Preparing the emulation system consists of the following steps: 

1. Plugging the emulator probe into your target system (for 
in-circuit emulation), not done in this getting started 
procedure. 

2. Accessing the emulator through the MEAS_SYS 
application. 

3. Modifying the default emulation configuration to match 
your system requirements by loading a configuration file. 
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4. Loading your absolute file into emulation memory 
(or target system memory when used). 

The following procedures use the emulator in out-of-circuit mode 
(no target system). Target system plug-in issues are discussed in 
detail in Chapter 6 of this manual. 


Accessing The 
Emulation System 


Access your emulation system as follows: 
1. Press MEAS_SYS. 


2. Press emul683k em68030 Return. 

You are now in the emulation system application. The emulation 
softkeys are displayed at the bottom of your screen. 


Modifying The 
Default Emulation 
Configuration 


When you accessed the emulator, the default emulation 
configuration file supplied with your system was loaded. You need 
to modify this default emulation configuration to create a 
configuration that supports your demonstration programs. A 
configuration file was supplied in the demonstration directory to 
make these modifications for you. All you need to do is load it. 


Load the demonstration configuration file using the command: 
load configuration config Return 


A listing of the demonstration configuration file is shown in figure 
3-1. The configuration file sets up the emulation memory map, and 
answers the emulation configuration questions. 

When the emulator is finished loading the memory mapper and 
background monitor, the STATUS line will show that the 
emulation processor is Reset. The emulator is ready to be used. 


Note 



You have two configuration files named "config” in your directory. 
File config.EB is a binary file used by the emulator. File config.EA 
is an ASCII file you can edit using an editor on your host system. 
Emulation configuration files provide an easy method to 
reconfigure your emulator for desired applications. 
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###################################**##*#*####*###########*################## 

# 

# This is the configuration file for the HP 64430 68030 Emulator/Analyzer 

# demonstration software. 

# If blocks of memory are mapped noncontigously the emulator allocates chunks 

# in multiples of 4k bytes. 

###################*######################################################### 

BEGIN MEMORY MAP 
modify default guarded 
modify valid_codes none 

### Map 124k memory for all prog and const sections to RAM. 
map 00H thru OlefffH emulation ram asynchronous width32 
### Map 12k memory for the emulation monitor to RAM. 
map 020000H thru 022fffH emulation ram asynchronous width32 
### Map 32k memory for the stack. 

map 07fff8000H thru 07fffffffH emulation ram asynchronous width32 
### Map 88k memory for all data sections. 

map OfffeaOOOH thru OffffffffH emulation ram asynchronous width32 
END MEMORY MAP 

Enable polling for simulated I/O? yes 
Function code data space ? none 
Simio control address 1? systemio_buf 
Enable polling for simulate3 interrupts? yes 
Function code data space ? none 

Simulated interrupt control address? _sim_int_ca 

Maximum delay (in milliseconds) for simulated interrupt? 3000 

Restrict to real-time runs? no 

Enable emulator use of the monitor? yes 

Reset into the monitor? yes 

Enable emulator use of INT7? yes 

Enable user IPEND line during emulator breaks? no 
Enable emulator use of software breakpoints? yes 
Software BKPT instruction number (0..7)? 7 

Default stack pointer for background? 07ffffff8h 
Perform periodic foreground accesses while in monitor? no 
Address for periodic foreground access? 0 
Enable foreground monitor? yes 

Interlock or provide termination for foreground? terminate 

Any custom registers? no 

Name of custom register format file? 

Break processor on write to ROM? no 

Block BERR on non-interlocked emulation memory? no 

In-circuit emulation session? no 

Enable DMA transfers? yes 

Enable DMA transfers into emulation memory? no 
CPU clock rate faster than 25 MHz? no 
Disable on-chip cache? yes 
MMU enabled during session? no 




Figure 3-1. 


Demonstration Configuration File 
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Simio control 
Simio control 
Simio control 
Simio control 
Simio control 
File used for 
File used for 
File used for 
Block ECS, OCS 


address 2? SIMIO_CA_TWO 

address 3? SIMIO_CA_THREE 

address 4? SIMIO_CA_FOUR 

address 5? SIMIO_CA_FIVE 

address 6? SIMIO CA__SIX 

standard input? 7dev/simio/keyboard 
standard output? /dev/simio/display 
standard error? /dev/simio/display 
signals during background monitor cycles? 


yes 


Figure 3-1. Demonstration Configuration File (Cont’d) 


Loading Emulation 
Memory 


You are ready to begin an emulation session. Before performing 
emulation, you must load emulation memory with the absolute file 
created from your source program modules. To load emulation 
memory, enter the following command: 


load memory towers Return 


Using The 
Emulator 


This section demonstrates the use of some of the basic emulator 
commands. Work through the examples in the sequence given in 
this section. Otherwise, the displays you get on your workstation 
screen may not be the same as those shown in the manual. After 
you have worked through the examples in this section, you may 
then execute other commands to gain a better understanding of the 
emulator’s operation. See the 68030 Analysis Specifics User’s Guide 
and the Reference Manual for 16- and 32 -Bit Internal Analysis for 
detailed information on using the emulator’s analysis features. 


Note 



The displays you obtain on your system for the examples in the 
following sections of this chapter may vary from those shown in 
this manual, depending on the type of terminal or workstation you 
are using. 
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Displaying Global The display global_symbols command displays global (externally 
Symbols defined) symbols in the program modules you have loaded into 
emulation or target memory. To display global symbols, enter the 
following command: 

display global_symbols Return. 



You should see a display similar to the following display on your 
screen. 


Global symbols in 
Procedure symbols 

towers 





Procedure 

name 

Address range 

Return 

Segment 

Offset 

_fflush 


00005B04- 

00005BBB 

00005BBA 

PROG 

000000F2 

_bufsync 


00005ED2- 

00005F0F 

00005F0E 

PROG 

000004C0 

dbl to str 

00003728- 

00003C15 

00003C14 

COMM 

000001E8 

doprnt 


00003F3C- 

00004F7D 

00004F7C 

COMM 

000000AC 

doscan 


00004FD6- 

00005291 

00005290 

PROG 

00000000 

exec funcs 

00001E86- 

00001EA5 

00001EA4 

PROG 

00000032 

_filbuf 


000058E8- 

00005A11 

00005A10 

PROG 

00000000 

_findbuf 


00005D86- 

00005E27 

00005E26 

PROG 

00000374 

_flsbuf 


00005BBC- 

00005CE9 

00005CE8 

PROG 

000001AA 

_memccpy 


000061E0- 

0000620B 

0000620A 

PROG 

00000000 

__startup 


000009AE- 

00000AE5 

00000AE4 

PROG 

00000000 

wrtchk 


00005E28- 

00005ED1 

00005ED0 

PROG 

00000416 

_xflsbuf 


00005CEA- 

00005D85 

00005D84 

PROG 

000002D8 

atexit 


00001E54— 

00001E85 

00001E84 

PROG 

00000000 

atof 


00002B4 2- 

00002BC7 

00002 BC 6 

COMM 

00000C9A 

STATUS: 

M68030- 

-Reset 




_. . .R_ 

display 

global^ 

symbols 





run 

trace 

set step 

display modify end 

-ETC — 



You can use the UP and DOWN cursor keys and the NEXT and 
PREV keys to scroll or page through the global symbols listing. 
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Displaying Local You can view local symbols within a file or module using the 

Symbols display local_symbols_in command. To view local commands in 
the demonstration program, enter the following command: 

display local_symbols_in towers.c: Return. 


Symbols in towers 

c: 





Procedure symbols 






Procedure name 

Address range 

Return 

Segment 

Offset 

ask for number 

0000120C- 

0000138B 

0000138A 

PROG 

000000B0 

init_display 

00001612- 

000016C7 

000016C6 

PROG 

000004B6 

main 

00001162- 

00001205 

00001204 

PROG 

00000006 

move disc 

00001584- 

0000160B 

0000160A 

PROG 

00000428 

pause 

00001392- 

000013C7 

000013C6 

PROG 

00000236 

place_disc 

00001526- 

0000157D 

0000157C 

PROG 

000003CA 

remove disc 

000014D2- 

0000151F 

0000151E 

PROG 

00000376 

show_discs 

000013CE- 

000014CB 

000014CA 

PROG 

00000272 

towers 

000016CE- 

00001745 

00001744 

PROG 

00000572 

Static symbols 






Symbol name 

Address range 


Segment 

Offset 

S from 


oooooooc 




S reg_paraml 


00000008 




S reg_j?aramlO 


00000014 




STATUS: M68030-- 

-Reset 




_...R.... 

display local symbols in towers. 

c: 




run trace 

set step 

display modify end 

-ETC — 


Note that the \c" file extension is used to specify C language files 
and the ".s" file extension is used to specify assembly language files. 
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Displaying Memory The display memory command enables you to view the contents of 

either emulation or target memory locations. Enter the command: 

display memory main mnemonic Return 


Memory :mnemonic 
address data 


1162 

4E560000 

LINK. W 

A6,#$0000 

1166 

2F0B 

MOVE. L 

A3,-(A7) 

1168 

2F0A 

MOVE. L 

A2,-(A7) 

116A 

45ED800C 

LEA 

($800C,A5),A2 

116E 

47FA0222 

LEA 

($0222,PC) f A3 

1172 

4EB90000+ 

JSR 

$00000036 

1178 

42AD8008 

CLR.L 

($8008,A5) 

117C 

60000068 

BRA .W 

$000011E6 

1180 

4E71 

NOP 


1182 

48780001 

PEA 

$00000001 

1186 

4EB80DEE 

JSR 

$00000DEE 

118A 

588F 

ADDQ.L 

#4, A7 

118C 

42AD8010 

CLR.L 

($8010,A5) 

1190 

42A7 

CLR.L 

~ (A7 ) 

1192 

4EBA047E 

JSR 

($047E,PC) 

1196 

588F 

ADDQ.L 

#4 , A7 


STATUS: M68030—Reset_. . .R_ 

display memory main mnemonic 


run trace set step display modify end -ETC— 


The first address listed in the display is 1162h, the address 
corresponding to the local symbol main in the local symbols 
display of the towers program. Use the UP and DOWN cursor keys 
and the NEXT and PREV keys to scroll or page through the 
memory display. 
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Modifying Memory You can modify emulation memory locations mapped as either 

RAM or ROM. The speed of the towers demonstration program is 
controlled by the variable loc_delay. We will set the value of 
loc_delay to 0 so that the program runs at maximum speed. In 
order to watch the memory display change as the variable is 
modified, we will display an area in memory repetitively and then 
modify the memory. Enter the following command: 

display memory loc_delay long repetitively Return 

You should see a display similar to the following on your 
workstation screen. 


Memory :long 

words :blocked :repetitively 



address data 

: hex 



:ascii 


1748-57 

000001F4 

09095075 

7A7A6C6 5 

20776974 

.Pu 

zzle wit 

1758-67 

68202564 

20646973 

63732063 

616E2062 

h %d dis 

cs can b 

1768-77 

6520736F 

6C766564 

20696E20 

2564206D 

e solved 

in %d m 

1778-87 

6F766573 

2E202020 

20200A00 

0A0A4578 

oves. 

. . . .Ex 

1788-97 

65637574 

6520276D 

6F646966 

79206B65 

ecute 'm 

odify ke 

1798-A7 

79626F61 

72645F74 

6F5F7369 

6D696F27 

yboard t 

o_simio' 

17A8-B7 

20746865 

6E20656E 

74657220 

6F6E6520 

then en 

ter one 

17B8-C7 

6F662074 

68652066 

6F6C6C6F 

77 696E67 

of the f 

ollowing 

17C8-D7 

3A0A094E 

756D6265 

7 2206F66 

20646973 

:..Numbe 

r of dis 

17D8-E7 

63732074 

6F207573 

65205B31 

2D25645D 

cs to us 

e [l-%d] 

17E8-F7 

0A092730 

2720746F 

20657869 

74207072 

0 

-p 

o 

exit pr 

17F8-07 

6F677261 

6D0A0927 

43272074 

6F207275 

ogram..' 

C' to ru 

1808-17 

6E20636F 

6E74696E 

756F7573 

6C792075 

n contin 

uously u 

1818-27 

73696E67 

206C6173 

74206E75 

6D626572 

sing las 

t number 

1828-37 

20656E74 

65726564 

0A0A003F 

00256400 

entered 

...?.%d. 

1838-47 

20696E76 

616C6964 

20726570 

65617420 

invalid 

repeat 

STATUS: M68030 

—Reset_ 





. . .R_ 

display memory 

loc_delay long repetitively 



run trace 

set 

step 


display 

modify end 

-ETC — 
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Enter the command: 


modify memory long locjielay to 0 Return 

Note that the first long word in the display (memory location 
loc_delay) now shows a long word value of OOOOOOOOh. 


Memory slong words :blocked :repetitively 



address 

data 

: hex 



:ascii 


1748-57 

00000000 

09095075 

7A7A6C65 

20776974 

.Pu 

zzle wit 

1758-67 

68202564 

20646973 

63732063 

616E2062 

h %d dis 

cs can b 

1768-77 

6520736F 

6C766564 

20696E20 

2564206D 

e solved 

in %d m 

1778-87 

6F76657 3 

2E202020 

20200A00 

0A0A4578 

oves. 

■ • • • Ex 

1788-97 

65637574 

6520276D 

6F646966 

79206B65 

ecute 'm 

odify ke 

1798-A7 

79626F61 

72645F74 

6F5F7369 

6D696F27 

yboard_t 

o simio' 

17A8-B7 

20746865 

6E20656E 

74657220 

6F6E6520 

then en 

ter one 

17B8-C7 

6F662074 

68652066 

6F6C6C6F 

77696E67 

of the f 

ollowing 

17C8-D7 

3A0A094E 

756D6265 

72206F66 

20646973 

:..Numbe 

r of dis 

17D8-E7 

63732074 

6F207573 

65205B31 

2D25645D 

cs to us 

e [l-%d] 

17E8-F7 

0A092730 

2720746F 

20657869 

74207072 

. . ' 0' to 

exit pr 

17F8-07 

6F677261 

6D0A0927 

43272074 

6F207275 

ogram..' 

C' to ru 

1808-17 

6E20636F 

6E74696E 

756F7573 

6C792075 

n contin 

uously u 

1818-27 

73696E67 

206C6173 

74206E75 

6D626572 

sing las 

t number 

1828-37 

20656E7 4 

65726564 

0A0A003F 

00256400 

entered 

...?.%d. 

1838-47 

20696E7 6 

616C6964 

20726570 

65617420 

invalid 

repeat 

STATUS: M68030—Reset 





. . .R- 

modify memory 

long loc_delay to 

0 




run trace 

set 

step 


display 

modify end 

-ETC— 


Running from the Now that you have used some of thedisplay and modify features of 
Transfer Address the emulator, it is time to run the demonstration program and use 

some of the run time features of the emulation system. Enter the 
following command: 

run from transfer_address Return 
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The STATUS line displays "M68030-Running". This indicates that 
the demonstration program is executing. 

Displaying Registers The display registers command enables you to look at the contents 

of the 68030’s CPU registers and the contents of the on-board 
MMU registers. Enter the following command: 

display registers cpu Return 

The contents of the following 68030 CPU registers are displayed on 
the screen: 

program counter (PC) 
source function code register (SFC) 
destination function code register (DFC) 
data registers (D0-D7) 
address registers (A0-A7) 


M68030 Registers 








NextPC 

00000C18 

SFC 

0 MOT RSVD 


DFC 

0 MOT RSVD 


D0-D7 

00000092 

00000001 

00000092 000058E8 

000000FF 

00000000 

00000064 

00000000 

A0-A6 

000000FF 

FFFEA057 

FFFEA484 FFFEA57 4 

FFFEA054 

FFFF21A8 

7FFFFDF0 


USP 

7FFFFFF0 


1 tO s m 

i 

x n z 

v c 

CAAR 00000000 

MSP 

7FFFFFF0 

STATUS 

2708 001 

0 

7 0 1 

0 0 0 

VBR 

00000000 

*ISP 

7FFFFDE4 


wa dbe 

fd 

ed ibe 

f i ei 





CACR 

0000 0 0 

0 

0 0 

0 0 



STATUS: 

M68030- 

--Running 






. . .R_ 

display registers cpu 







run 

trace 

set 

step 


display 

modify 

end 

-ETC — 
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user stack pointer (USP) 
vector base register (VBR) 
cache address register (CAAR) 
master stack pointer (MSP) 
interrupt stack pointer (ISP) 
status register (STATUS) 
cache control register (CACR) 

Press the break softkey, then press Return. 

The registers display is updated and the status line now reads 
"STATUS: M68030--Running in monitor". If a display registers 
command has been executed in the current emulation session, the 
registers display is updated whenever a break to the emulation 
monitor program occurs. 


H68030 Registers 








NextPC 

00000C18 

SFC 

0 MOT RSVD 


DFC 

0 MOT RSVD 


DO-D7 

00000092 

00000001 

00000092 000058E8 

OOOOOOFF 

00000000 

00000064 

00000000 

A0-A6 

000000FF 

FFFEA057 

FFFEA484 FFFEA574 

FFFEA054 

FFFF21A8 

7FFFFDF0 


USP 

7FFFFFF0 


1 tO s m 

i 

x n z 

v c 

CAAR 00000000 

MSP 

7FFFFFF0 

STATUS 

2708 001 

0 

7 0 1 

0 0 0 

VBR 

00000000 

*ISP 

7FFFFDE4 


wa dbe 

fd 

ed ibe 

f i ei 





CACR 

0000 0 0 

0 

0 0 

0 0 



NextPC 

00000C12 

SFC 

0 MOT RSVD 


DFC 

0 MOT RSVD 


D0-D7 

00000000 

00000001 

00000092 000058E8 

OOOOOOFF 

00000000 

00000064 

00000000 

A0-A6 

OOOOOOFF 

FFFEA057 

FFFEA484 FFFEA574 

FFFEA054 

FFFF21A8 

7FFFFDF0 


USP 

7FFFFFF0 


1 tO s m 

i 

x n z 

v c 

CAAR 00000000 

MSP 

7FFFFFF0 

STATUS 

2704 001 

0 

7 0 0 

10 0 

VBR 

00000000 

*ISP 

7FFFFDE4 


wa dbe 

fd 

ed ibe 

f i ei 





CACR 

0000 0 0 

0 . 

0 0 

0 0 



STATUS: 

M68030- 

—Running_ 






. . .R_ 

break 









load 

store 

copy 

break 


reset 



-ETC— 


3-18 Getting Started 




Using The Step The step function enables you to step through your program 

Function Opcode by opcode. Each time the step command is executed, one 
program instruction is executed. Enter the command: 

step from transfer_address Return 

The register display is updated each time a step is executed. In the 
last entry on the display an additional line is displayed. The address 
of the instruction executed by the step command and the executed 
instruction are displayed on the first line of the new register display 
entry. The step feature is a powerful tool for debugging programs 
because it enables you to watch the register activity for each 
executed instruction. 


M68030 Registers 








NextPC 

00000C18 

SFC 

0 MOT RSVD 


DFC 

0 MOT RSVD 


D0-D7 

00000092 

00000001 

00000092 000058E8 

000000FF 

00000000 

00000064 

00000000 

A0-A6 

000000FF 

FFFEA057 

FFFEA484 FFFEA57 4 

FFFEA054 

FFFF21A8 

7FFFFDF0 


USP 

7FFFFFF0 


1 tO S m 

i 

x n z 

V C 

CAAR 00000000 

MSP 

7FFFFFF0 

STATUS 

2708 001 

0 

7 0 1 

0 0 0 

VBR 

00000000 

*ISP 

7FFFFDE4 


wa dbe 

fd 

ed ibe 

f i ei 





CACR 

0000 0 0 

0 

0 0 

0 0 



PC 

00000400 

Opcode 

LEA 

$80000000,A7 



4FF98000 

NextPC 

00000406 

SFC 

0 MOT RSVD 


DFC 

0 MOT RSVD 


D0-D7 

00000092 

00000001 

00000092 000058E8 

000000FF 

00000000 

00000064 

00000000 

A0-A6 

000000FF 

FFFEA057 

FFFEA484 FFFEA574 

FFFEA054 

FFFF21A8 

7FFFFDF0 


USP 

7FFFFFF0 


1 tO s m 

i 

x n z 

v c 

CAAR 00000000 

MSP 

7FFFFFF0 

STATUS 

2708 001 

0 

7 0 1 

0 0 0 

VBR 

00000000 

*ISP 

7FFFFFF8 


wa dbe 

fd 

ed ibe 

f i ei 





CACR 

0000 0 0 

0 

0 0 

0 0 



STATUS s 

M68030- 

--Running 






... R... . 

step 

from transfer_address 






run 

trace 

set 

step 


display 

modify 

end 

-ETC — 
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Enter the command: 


step Return 

Note that the emulator executes the instruction stored in the 
NextPC memory location. Press Return repetitively. The emulator 
executes one instruction each time you press Return. 

The step instruction enables you to specify a number of steps. This 
is useful when stepping through program structures such as delay 
loops. Enter the command: 

step 25 Return 

Notice that the screen is updated with register information each 
time a program step is executed. While the step command is being 
executed, the status line displays the message "MC68030~Steps left 
#n" where n is the number of steps remaining. You can use the 
NEXT and PREV keys and the UP and DOWN keys to look at 
register information that has scrolled off of the screen. 

Tracing Processor The trace function (with analyzer present) enables you to watch 
Activity each cycle on the processor bus as it occurs. The following 

examples illustrate some simple uses of the trace function. For 
more information on the trace function, refer to the Analysis 
Reference Manual for 32-Bit Microprocessors and the 68030 Analysis 
Specfics User's Guide . 

Enter the command: 

trace TRIGGER__ON a= Iong_aligned main Return 

This sets up a trace of all activity of the bus for 2k bus cycles before 
and 2k bus cycles after the address labeled main occurs. The 
STATUS line will indicate "Trace in process". Enter the command: 

run from main Return 
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After the STATUS line indicates "Trace complete", enter the • 
command: 

display trace Return 

The trace list is displayed on the screen with the trigger state 
displayed in the center of the screen. Notice the lines prior to the 
trigger state. The address field shows that these lines represent 
emulation monitor execution and stack accesses. User program 
activity is displayed starting with the trigger state (00001160h). 


Trace List 




Mode:logical 

data 


Label: 

Address 


Opcode or Status 




time count 

Base: 

hex 



mnemonic 





relative 

-0007 

00000638 

$4E714E7 3 

supr 

prgm 

long 

rd 

log 

addr 

(ds32) 

0.12us 

-0006 

00001FF0 

$41-— 

supr 

prgm 

byte 

rd 

log 

addr 

(ds32) 

0.16us 

-0005 

000006 3C 

$00000BF6 

supr 

prgm 

long 

rd 

log 

addr 

(ds32) 

0.08us 

-0004 

7FFFFDE4 

$2704- 

supr 

data 

word 

rd 

log 

addr 

(ds32) 

0.76us 

-0003 

7FFFFDEA 

$-007C 

supr 

data 

word 

rd 

log 

addr 

(ds32) 

0.24us 

-0002 

7FFFFDE6 

$-oooo 

supr 

data 

long 

rd 

log 

addr 

(ds32) 

0.24us 

-0001 

7FFFFDE8 

$1162- 

supr 

data 

word 

rd 

log 

addr 

(ds32) 

0.20us 

trigger 

00001160 

$4E714E56 

supr 

prgm 

long 

rd 

log 

addr 

(ds32) 

0.40us 

+0001 

00001164 

$00002F0B 

supr 

prgm 

long 

rd 

log 

addr 

(ds32) 

0.24us 

+0002 

00001168 

$2F0A4 5ED 

supr 

prgm 

long 

rd 

log 

addr 

(ds32) 

0.28us 

+ 0003 

7FFFFDE8 

$7FFFFDF0 

supr 

data 

long 

wr 

log 

addr 

(ds32) 

0.24us 

+ 0004 

0000116C 

$800C47FA 

supr 

prgm 

long 

rd 

log 

addr 

(ds32) 

0.24us 

+0005 

7FFFFDE4 

$FFFEA574 

supr 

data 

long 

wr 

log 

addr 

(ds32) 

0.24us 

+ 0006 

7FFFFDE0 

$FFFEA484 

supr 

data 

long 

wr 

log 

addr 

(ds32) 

0.28us 

+ 0007 

00001170 

$02224EB9 

supr 

prgm 

long 

rd 

log 

addr 

(ds32) 

0.28us 

STATUS: 

M68030-- 

-Running 


Trace complete 


__ ...R_ 

display 

trace 










run 

trace 

set step 



display 

modify 

end 

-ETC — 



c 
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The address and data values in the default trace list are displayed as 
hexadecimal numbers. The emulator can also display values in 
assembly language mnemonics. Enter the command: 

display trace disassemble_from_line_number 0 Return 


Trace List 


Mode 

:logical 

data 


Label: 

Address 


Opcode or Status 



time count 

Base: 

hex 


mnemonic 



relative 

trigger 

00001160 

NOP 




0.40us 

= 

00001162 

LINK.W 

A6,*$0000 




+0001 






0.24us 

= 

00001166 

MOVE.L 

A3,-(A7) 




+0002 

00001168 

MOVE.L 

A2,-(A7) 



0.28us 

= 

0000116A 

LEA 

($800C,A5),A2 




+0003 

7FFFFDE8 

$7FFFFDF0 

supr data long wr 

log addr 

(ds32) 

0.24us 

+0004 






0.24us 

= 

0000116E 

LEA 

($0222,PC),A3 




+0005 

7FFFFDE4 

$FFFEA574 

supr data long wr 

log addr 

(ds32) 

0.24us 

+0006 

7FFFFDE0 

$FFFEA484 

supr data long wr 

log addr 

(ds32) 

0.28us 

+0007 






0.28us 

= 

00001172 

JSR 

$00000036 




+0008 

00001174 

$00000036 

supr prgm long rd 

log addr 

(ds32) 

0.28us 

+0009 

00000034 

NOP 




0.36us 

STATUS: 

M68030- 

-Running 

Trace complete 


_...R_ 

display 

trace disassemble_ 

from_line_number 0 




run 

trace 

set 

step display 

modify 

end 

-ETC — 


Note that in the updated trace display, the trigger line (line 0) is 
the first line in the trace display. Address 00001160h corresponds 
to the main label in the demonstration program. The instruction 
MOVE.Lon the trigger line is the first instruction in the example 
program. 
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You can also display the source program lines corresponding to the 
traced assembly level code in the trace list. Enter the command: 

display trace source on inverse_video on Return 


Trace List 

Mode:logical data 


Label: 

Address 

Opcode or Status w/ Source Lines 

time count 

Base: 

hex 

mnemonic 

relative 

trigger 

00001160 NOP 


0.40us 


##########towers.c - line 1 thru 128 #########*#################### 

static void towers(); 

static int ask_for_number(); 


main() 
{ 


= 

00001162 

LINK.W 

A 6 ,#$0000 


+ 0001 




0.24us 

= 

00001166 

MOVE.L 

A3,-(A7) 


+ 0002 

00001168 

MOVE.L 

A2,-(A7) 

0.28us 

= 

0000116A 

LEA 

($800C,A5),A2 


+ 0003 

7FFFFDE8 

• $7FFFFDF0 

supr data long wr log addr (ds32) 

0.24us 

+ 0004 




0.24us 

= 

0000116E 

LEA 

($0222,PC),A3 


STATUS: 

M68030-- 

-Running 

Trace complete 

_. ..R.. 

display 

trace 

source on 

inverse__video on 



run trace set step display modify end -ETC— 


The display is updated with the source code line displayed in 
inverse video immediately before the related traced assembly level 
code. 

You can use the UP and DOWN cursor keys or the NEXT and 
PREV keys to scroll or page through the entire trace listing. You 
can copy the trace list to the printer or a file as well. 
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Using Software 
Breakpoints 


The set sw_breakpoints command lets you set software breakpoints 
in your program code. This useful feature lets you break execution 
of your program at the point you select. You can then use the many 
display and modify commands available in the emulator to examine 
and debug your code. The emulator replaces the code at the 
memory location you specify with a 68030 BKPT instruction. You 
select the appropriate BKPT instruction when answering the 
emulation configuration questions. Enter the command: 

break Return 

You are now running in the emulator monitor program. Enter the 
command: 

modify swjbreakpoints set one-shot towers.c:ask_for jnumber 
Return 

This command causes the emulator to replace the instruction at 
the address reference by the symbol ask_forjnumber (0000120CH) 
with a BKPT 7 instruction. The address specified in the command 
must be tie first address of an opcode. Enter the following 
command: 

display memory towers.c:ask_for_number mnemonic Return 
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The display shows a BKPT 7 instruction at address 0000120CH. 


Memory 

mnemonic 





address data 





120C 

484F 

BKPT 

#7 



120E 

000048E7 

ORI.B 

#$E7,DO 



1212 

3E38242E 

MOVE.W 

$0000242E,D7 



1216 

0008200D 

ORI.B 

#S0D,A0 



121A 

06 80FFFF+ 

ADDI.L 

# $FFFF82DC,DO 



1220 

2440 

MOVEA.L 

DO , A2 



1222 

47FB8170+ 

LEA 

($00004FE8,PC),A3 



122A 

49FB8170+ 

LEA 

($00005030,PC),A4 



1232 

2042 

MOVEA.L 

D2,A0 



1234 

2610 

MOVE.L 

(A0),D3 



1236 

4AAD8008 

TST.L 

($8008,A5) 



123A 

6600013E 

BNE.W 

$0000137A 



123E 

48780001 

PEA 

$00000001 



1242 

4EB80DEE 

JSR 

$00000DEE 



1246 

588F 

ADDQ.L 

# 4 , A7 



1248 

48780007 

PEA 

$00000007 



STATUS: M68030— Running 

Trace complete 


_ ...R.... 

display memory towers.c:ask_for_ 

number mnemonic 



run trace set step 

display modify 

end 

-ETC — 





Enter the command: 

run from transfer_address Return 

The demonstration program runs from the transfer_address 
(jnain) until the BKPT instruction is executed. The BKPT 
instruction causes the emulator to break into the emulation 
monitor and the message "STATUS: Software breakpoint hit at 
address = 120CH" is displayed on the status line. 

The emulator’s ability to let you set software breakpoints provides 
you with a method of stopping program execution at a specified 
point in your program. You can then examine register values, 
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display or modify memory locations, and perform other operations 
before continuing execution of your program. 

Enter the command: 

display memory towers.c:ask_for_number Return 

Note that the instruction LINK.W is now displayed at address 
120CH in the memory listing. After breaking into the emulation 
monitor, the emulator replaces the BKPT instruction with the 
original contents of the memory location (LINK.W instruction). 


Memory 

:mnemonic 



address data 



120C 

4E560000 

LINK.W 

A6 f #$0000 

1210 

48E73E38 

MOVEM. L 

rm=$3E38,- (A7) 

1214 

242E0008 

MOVE. L 

($0008 f A6),D2 

1218 

200D 

MOVE .L 

A5 , DO 

121A 

0680FFFF+ 

ADDI.L 

# $ FFFF8 2 DC, DO 

1220 

2440 

MOVE A. L 

DO ,A2 

1222 

47FB8170+ 

LEA 

($00004FE8,PC) f A3 

122A 

49FB8170+ 

LEA 

($00005030,PC),A4 

1232 

2042 

MOVEA.L 

D2 f A0 

1234 

2610 

MOVE. L 

(A0),D3 

1236 

4AAD8008 

TST.L 

($8008,A5) 

123A 

6600013E 

BNE.W 

$0000137A 

123E 

48780001 

PEA 

$00000001 

1242 

4EB80DEE 

JSR 

$00000DEE 

1246 

588F 

addq.l 

#4, A7 

1248 

48780007 

PEA 

$00000007 


STATUS: M68030—Running in monitor Trace complete_...R.... 

display memory towers. c:ask__for_number 

run trace set step display modify end -ETC— 
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Using Simulated I/O 


To continue execution of your program from the point the break 
occurred, enter the command: 

run Return 

Notice that the status line now reads "M68030~Running". 

Refer to chapter 10 for a description of how the software 
breakpoint function is implemented in the 68030 emulator. See 
chapter 2 of the 68030 Emulation Reference Manual for the 
software breakpoint command syntax. 

The demonstration program uses simulated I/O for both entering 
parameters and displaying the solution to the towers of Hanoi 
problem. To display the simulated I/O screen, enter the command: 

display simulated_io Return 
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Your screen should appear as shown in the following display. 


Simulated I/O display Simulated I/O command: read 

display is open Return code: 00H 

Execute 'modify keyboard_to_simio' then enter one of the following: 
Number of discs to use [1-7] 

'0' to exit program 

'C' to run continuously using last number entered 


? 


STATUS: M68030—Running Trace complete_. . .R. . . . 

display simulated_io 


run trace set step 


display modify end -ETC— 


The keyboard must be assigned to simulated I/O before it can be 
used to specify the number of discs to be used in the program. 
Enter the command: 

modify keyboard_to_simio Return 

The keyboard is now assigned to simulated I/O and is accessible to 
the demonstration program. Enter the number 7 and press Return. 
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The program then uses simulated I/O to display the solution to the 
problem on the screen as shown in the following display. 


Simulated I/O display Simulated I/O command: write 

display is open Return code: 00H 


1 

1 

333 | 

1 

1 

1 333 

II 

II 

II 

II 

II 

II 

4444 | 

| 4444 

II 

ii 

55555 | 

| 55555 

II 

M 

666666 | 

| 666666 

II 

ii 

7777777 | 

| 7777 777 

22||22 

1 11 

Peg 

0 

Peg 1 

Peg 


Solution for Towers with 7 discs. 

Move #3: Move disk 1 from peg 2 to peg 1 
0 simulated interrupts have been serviced. 


STATUS: M68030—Running Trace complete 


suspend 


To return control of the keyboard to the host system, press the 
suspend softkey. The normal emulation softkeys will be restored. 

For more information on using simulated I/O, see chapter 4 and 
the Simulated HO O perating Manual supplied with your 
HP 64000-UX system. 
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Using the 
DeMMUer 


Use this procedure only if you have a deMMUer in your 
emulation/analysis system hardware, and you intend to include the 
functionality of the 68030 MMU in your system. This procedure 
briefly shows how the deMMUer translates physical addresses 
which are created by the 68030 MMU into logical addresses for use 
by the internal analyzer. For more detailed information on 
DeMMUer operation, refer to the 69030 Internal Analyzer User's 
Guide. 

The internal analyzer needs logical addresses in order to accept 
commands you specify using source-file symbols and segment 
names, and to provide trace lists that show address values using the 
names of symbols and segments defined in the source file. 

Enter the following commands: 

reset Return 

load configuration virtual Return 
load memory physical os Return 

The "os" program is a short operating-system script that sets up the 
68030 MMU to manage memory for this demonstration program. 

It allocates 1 megabyte of physical memory for the emulator. It 
also sets up the deMMUer to match the MMU configuration in 
"os.s”. 

In this particular operating system script, physical memory is 
mapped 1:1 to logical memory. As a result, addresses do not 
change when the MMU is enabled. Mapping the memory 1:1 is not 
required for operation of the emulator, but it serves to simplify this 
example. Enter the following command: 

set analysis mode logical Return 

This command turns on the deMMUer so that it will supply logical 
addresses to the analyzer for storage in its trace memory. Notice 
that you can select the storage of either logical or physical 
addresses with this command. You will find logical address 
information most useful when developing application programs, 
and physical address information most useful when developing 
operating systems. The analyzer memory cannot store both logical 
and physical addresses for each state in trace memory; that is why 
you make this selection before you start the trace. 
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Start the analyzer and run the operating system program "os" by 
entering the following commands: 

trace Return 

display trace symbols on Return 
run from entry Return 

The "entry" symbol used in the last command is a symbol in the 
data base of the "os" program. This starts the "os" program running 
at the appropriate point. Your screen should appear as shown in 
the following display. 


Trace List 
Label: 

Base: 

-0007 

-0006 

-0005 

-0004 

-0003 

-0002 

-0001 


Address 

symbols 


Mode:logical address 

Opcode or Status time count 

mnemonic w/symbols relative 


STATUS: M68030—Running 

run from entry 


Trace complete^ 


trigger 

AB|entry.s:reset 

$00000E2A 

supr 

prgm 

long 

rd 

log 

addr - 

— 

— 

+0001 

abs 00000004 

$00000A00 

supr 

prgm 

long 

rd 

log 

addr 

0 . 

40us 

+ 0002 

ABS|STACKTOP 

$2700- 

supr 

data 

word 

wr 

log 

addr 

338.ms 

+0003 

abs 000F0F02 

$-000F 

supr 

data 

long 

wr 

log 

addr 

12 

. 2us 

+ 0004 

abs 000F0F04 

$0000- 

supr 

data 

word 

wr 

log 

addr 

0 . 

60us 

+0005 

abs 000F0F06 

$-0000 

supr 

data 

word 

wr 

log 

addr 

12 

. lus 

+0006 

ABS|STACKTOP 

$2700- 

supr 

data 

word 

rd 

log 

addr 

21 

. 4us 

+0007 

abs 000F0F06 

$-0000 

supr 

data 

word 

rd 

log 

addr 

0. 

40us 


trace 


set 


step 


display modify 


end -ETC— 
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Enter the following commands: 

break Return 

load memory towers Return 

The above command causes the towers program to be loaded 
logically through the monitor. (This requires several minutes.) 

trace TRIGGER_ON a= long_aligned main Return 
run from transfer_address Return 

The program will run about 15 seconds before the analyzer finds its 
trigger pointer and captures a trace. 

display trace disassemble_from_line_number 0 Return 
display trace source on inverse_video on Return 

In the resulting display that follows, you can see lines of source 
code (shown in inverse video on your screen), followed by the 
states in the trace memory that were emitted by those source lines 
The trigger line in the display shows the beginning of execution in 
the towers program. This program will run just like it did before 
you set out to use memory management. The deMMUer will 
provide all of the translations required to allow symbols to be used 
in analyzer commands, and to allow symbolic addresses to be 
shown in analyzer trace lists. 
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Trace 

List 

Mode : logical 

address 


Label: 


Address 

Opcode or Status 


time count 

Base: 


symbols 

mnemonic w/symbols 


relative 

trigger 

000010E8 NOP 



0.40us 


##########towers.c - line 1 thru 128 ############################## [ 


static void towers(); 





static int ask_for_number(); 




main() 






000010EA LINK.W 

A6,#$0000 



+0001 


7FFFFFC8 $00000A5C 

supr data long wr log addr 

(strm) 

0.40us 

+0002 





0.40us 


= 

000010EE MOVE.L 

A3,-(A7) 



+ 0003 


000010F0 MOVE.L 

A2,-(A7) 


0.4 8us 


= 

000010F2 LEA 

($800C,A5),A0 



+ 0004 


7FFFFFC4 $7FFFFFF0 

supr data long wr log addr 

(strm) 

0.40us 

+ 0005 





0.40us 

STATUS 

: 

M68030—Running 

Trace complete 



display 

trace source on inverse_video on 



run 


trace set 

step display modify 

end 

-ETC — 
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Ending The 
Emulation Session 


Using Command 
Files 


To end the emulation session, enter the command: 


end release_system Return 

The system will return to the MEAS_SYS application level. 

This completes your introduction to the 68030 emulation system. 
You have assembled and compiled program modules, linked your 
program modules, and used a few of the basic features of the 
emulation system. For more detailed operational information, 
refer to the information contained in the other chapters of this 
manual and the 68030 Emulation Rrference Manual . See the 
Analysis Reference Manual for 32J3it Microprocessors and the 
68030 Analysis Specfics User's Guide for detailed information on 
the analysis features provided in the emulator. 


A command file is a file that lists a series of commands that must 
be performed to accomplish a particular function. Command files 
are ideal for setting up, and accessing, the emulation system. Once 
the file is created, all you need to do is type the file name and press 
Return The commands in the file will be executed, allowing you to 
easily enter your emulation session. Refer to the "Creating and 
Using Command Files" chapter of th zHP 64000-UX User's Guide 
for detailed information on command files. 
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Answering Emulation Configuration Questions 


Overview This chapter: 

■ Explains each of the emulation configuration questions. 

■ Describes how to configure the emulator for compatibility 
with your 68030 target system. 

H Describes how to map your 68030 system memory to 
emulation and target system memory resources. 


Introduction The 68030 emulator is configured from within the emulation 

application. When you run emulation for the first time, a default 
configuration file is loaded. You can modify this file to match your 
particular system needs by answering a series of emulation 
configuration questions displayed on your workstation display. 
After modifying the emulation configuration, you can save it to a 
file which you can then load each time you enter emulation. 

Your answers to the emulation configuration questions define how 
your 68030 emulator is configured, how resources are shared 
between the emulator and your target system, how the emulator 
and target system interact, and what operations are enabled in the 
emulation environment. 
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The configuration questions enable you to do the following 
emulation configuration tasks: 

B Selecting real time or nonreal-time run mode. 

■ Enabling breaks to the emulation monitor. 

■ Selecting whether to reset into the emulation monitor or 
to use the user reset exception vector. 

a Configuring the foreground and background monitors. 

m Enabling and selecting the software breakpoint instruction. 

■ Configuring custom coprocessor functions. 

■ Configuring memory. 

■ Configuring the emulator pod. 

■ Configuring simulated I/O and interrupts. 

■ Naming your emulation configuration command file. 


Running Emulation The command sequence to run emulation depends on how you 

configured your emulation system and what you named it. In this 
chapter, the example names from chapter 3, Getting Started, are 
used. To run emulation, do the following steps: 

1. Press MEAS_SYS. 

2. Press emul683k em68030 Return. 
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Modifying The To modify the configuration, enter the following command: 

Configuration File 


modify configuration Return 

A series of questions are displayed on your workstation screen. 
Your answers to these emulation configuration questions specify 
the configuration of the emulation hardware and software for a 
specific application. Each question is displayed with a default 
response. Additional options are shown in this chapter in 
parentheses. The default response is selected by pressing the 
Return key. Other responses are selected by pressing the 
appropriate softkey or by typing in an appropriate response, and 
then pressing Return. If you are modifying an emulation 
configuration file which you previously made, the default responses 
are those responses stored in that configuration file. 


Note 


If you need to return to a question you have already answered, 
press the RECALL softkey. Each time you press RECALL, the 
emulator backs up to the configuration question that was displayed 
prior to the question currently displayed. You may then make any 
corrections needed. 
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Selecting Real-Time/ 
Nonreal-Time Run 
Mode 


Caution mh possible damage to circuitry: 

™ When the emulator detects a guarded memory access or other 

illegal condition, or when you execute a command that causes the 
emulator to break into the emulation monitor, the emulator stops 
executing the user program and enters the emulation monitor. If 
you have circuitry in your target system that can be damaged 
because the emulator is not executing your code, you should use 
caution. Restrict the emulator to run in real-time mode only. Do 
not execute commands that cause breaks to the emulation monitor. 


Real-time refers to the continuous execution of your 68030 
program without interference from the development environment 
except as specified by you. All commands which cause momentary 
breaks to the emulation monitor are disabled. Momentary breaks 
are breaks asserted by the emulation software which momentarily 
diverts 68030 execution to the emulation monitor and then 
resumes execution of your program. In real-time run mode, you can 
execute any command which does not cause a break to the 
emulation monitor. Commands requiring target memory or 
register accesses are disabled when a user program is running. 
These commands can only be executed while running in the 
emulation monitor. An attempt to execute a run/step from 
<ADDR> command while executing the user program in real time 
causes a break to the emulation monitor. 

If the emulator is not restricted to real-time run mode, all selected 
emulation functions are enabled. Commands requiring access to 
target memory, logical memory with the MMU, or registers cause a 
break to the emulation monitor if a user program is running. 

All real-time interference can be avoided by disabling the 
emulation monitor functions. You can select this option later in 
the configuration questions. 
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Figure 4-1 shows the display that appears with the following 
question. 

Restrict to real-time runs? no (yes) 

no All selected emulator functions are enabled. The 

emulation system is enabled to break to the emulation 
monitor whenever a command requiring breaks to the 
emulation monitor is executed. 

yes Target memory and register accesses are disabled when a 
user program is running. 


Not restricted to real time 


- All selected emulation functions are available. 

- Target memory or register accesses will cause a break/exit. 

- Run/step from ADDRESS will cause a break into the monitor. 

Restricted to real time 


- Target memory or register access, run/step from ADDRESS, etc 
only allowed while the emulator is running in monitor. 


STATUS: Configuring M68030.. 

Restrict to real-time runs? no 

yes no RECALL 


Figure 4-1. Restrict To Real-Time Runs Display 
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Enabling Emulator The next question asks you if you want to enable emulator use of 
Monitor Functions the monitor. If you answer yes, all emulation commands and 

features implemented by the emulation monitor are enabled. If 
you answer no, the next question asked is "Modify memory 
configuration?" and configuration questions that refer to functions 
requiring the emulation monitor will not be asked. They will be set 
to the following default values: 


Reset into the monitor? 

N - '’no 

Enable emulator use of INT7? 

- ' no 

Software BKPT instruction number (0..7)? 

' - 7 

Default stack pointer for background? 

Offffffffh 

Block ECS, OCS signals during background monitor cycles? 

yes 

Perform periodic foreground accesses while in monitor? 

no 

Enable foreground monitor? 

no 


If the emulation monitor is not loaded, all emulation functions that 
require the monitor for execution will be disabled and their 
associated softkeys turned off. The functions that require the 
emulation monitor are: 

■ automatic reset to monitor 

■ break 

■ copy target (logical memory with MMU enabled) 

B copy registers 

B display target (logical memory with MMU enabled) 

B display registers 

a emulator use of software breakpoints 
H load logical memory 

a modify target (logical memory with MMU enabled) 
a modify registers 
a run from/until <ADDR> 
a setbreak_on 
a step 

a store target memory (logical memory with MMU enabled) 


Figure 4-2 shows the display that appears with the following 
question. 

Enable emulator use of the monitor? yes (no) 
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Monitor disabled 


Configuration questions that refer to monitor functions will 
not be asked and will be defaulted. The host software will 
disable all features that rely on monitor support. 

Monitor enabled 


All emulation features using the monitor are enabled. 


STATUS; Configuring M68030.. 

Enable emulator use of the monitor? yes 

yes no RECALL 


Figure 4-2. Enable Emulation Monitor Display 


yes All emulation commands and features implemented with 
the emulation monitor are enabled. 

no Configuration questions that refer to functions requiring 
the emulation monitor are not asked. If no emulation 
monitor is loaded, all commands and features requiring 
the emulation monitor are disabled and their associated 
softkeys are turned off. If the MMU is enabled (in a later 
question), only direct physical memory accesses will 
succeed because logical address accesses are made through 
the monitor. The next question asked is "Modify memory 
configuration?". 
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Resetting Into The 
Monitor 


Note 



If you answered no to the previous question, the following question 
will not be displayed on your screen. 


r ' 


D. 


C\ r ( 






The next question lets you select whether the emulation reset 
command causes the processor to be reset into the emulation 
monitor or to the memory location specified by the user reset 
exception vector. This question only affects reset commands 
entered from the workstation keyboard or processor reset on entry 
to the emulation module. It has no effect on reset signals generated 
within the user’s target system. 

Figure 4-3 shows the display that appears with the following 
question. 

Reset into the monitor? yes (no) 

yes The emulation reset command causes the processor to be 
reset into the emulation monitor. The user-defined reset 
vector and initial stack pointer are ignored. 

no The emulation reset command causes the processor to 
fetch the user-defined reset vector and begin execution 
from that address. 
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Reset to monitor enabled 


A reset command, followed by a run command will cause the processor 
to enter the foreground monitor if it is enabled and loaded. The 
background monitor will be entered automatically after reset if the 
foreground monitor is not enabled. The user-defined reset vector will 
be ignored. 

Reset to monitor disabled 


A reset command, followed by a run command, will cause the processor 
to fetch the user-defined reset vector and execute from that point. 


STATUS: Configuring M68030.. 

Reset into the monitor? yes 

yes no RECALL 


Figure 4-3. Reset Into Monitor Display 


Figure 4-4 shows the display that appears with the following 
question. 

Enable emulator use of INT7?/^es (no) 


I/);' 


c if 


" !l JWJ 


\ c\* P A 
■ '\\L ' 


SI O 


The emulation break function uses the level 7 interrupt autovector 
(INT7) processor resource to force the user program to be 
interrupted and the emulation monitor program to be entered. 
This question lets you enable or disable the emulation break 
function, as required for your target system. If your target system 
cannot share INT7 with the emulator, you need to answer no to 
this question. 
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Emulator use of INT7 enabled 


All selected emulation functions are available. 

Emulator use of INT7 disabled 


All emulation break signals are blocked to the processor. 

The following are the only ways to enter the monitors 

- user program jumps to the monitor 

- exectiited exception vector points to the foreground monitor 

- a software breakpoint is hit 

- reset command with reset-to-monitor function enabled 


STATUS: Configuring H68030.. 

Enable emulator use of INT7? yes 

yes no RECALL 


Figure 4-4. Enable Emulator Use of INT7 Display 


yes All selected emulation functions are available. 

no All emulation break signals to the processor are disabled. 
The only ways to enter the monitor program are: 

■ user program jumps to the monitor 

■ executed exception vector points to the foreground 
monitor 

u software breakpoint is executed 

u reset command with reset-to-monitor function 
enabled. 
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Note 


If you answered no to the previous question, this question will not 
be displayed on your screen. 



Figure 4-5 shows the display that appears with the following 
question. 

Enable user IPEND line during emulator breaks^ no (yes) 


no The interrupt pending signal (IPEND) is 

blocked (driven high) for emulator driven 
interrupts. Target system generated 


IPEND during emulation breaks disabled 


An emulator-generated break will not send an interrupt pending 
signal (IPEND) to the target system. Target system interrupts 
will be acknowledged normally. 

IPEND during emulation breaks enabled 


Any interrupt will send the interrupt pending signal (IPEND) to 
the target system. 


STATUS: Configuring M68030.. 

Enable user IPEND line during emulator breaks? no 

yes no RECALL 


Figure 4-5. Enable User IPEND Display 
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interrupts cause the IPEND signal to be 
unblocked (driven low). 


Enabling Emulator 
Use of Software 
Breakpoints 


Selecting The 
Software Breakpoint 
Instruction Number 


Note 


yes Any interrupt sends the interrupt pending 

signal (IPEND) to the target system. 


Software breakpoints must be enabled to allow the language 
system to pass messages into the background monitor. The next 
question lets you specify whether or not the emulator can use the 
68030 BKPT instructions to do software breaks from the user 
program into the emulation monitor. The modify swjbreakpoints 
set and run until commands are disabled if you answer no to this 
question. You should answer no only if your target system must use 
all eight 68030 BKPT instructions. 

Enable emulator use of software breakpoints? yes (no) 



The emulator software breakpoint functions 
are enabled. 


no 


Emulator use of software breakpoints is 
disabled. 


The following question lets you specify which of the eight 68030 
BKPT instructions the emulator uses to execute software breaks 
into the emulation monitor. 


If you answered no to the previous question, this question will not 
be displayed on your screen. 


Figure 4-6 shows the display that appears with the following 
question. 


Software BKPT instruction number (0..7)? 7 (< number >) 
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Software breakpoint instruction number 


This sets the breakpoint number for the emulation software 
breakpoint (i.e. BKPT #x, where x is the breakpoint number 
selected). 


STATUS: Configuring M68030_ 

Software BKPT instruction number (0..7)? 7 


< number > 


Figure 4-6. Software Breakpoint Instruct No. Display 
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Defaulting The Stack 
Pointer For The 
Background Monitor 


This question allows you to set the address value to be used to exit 
the background monitor if the monitor is entered from reset. The 
default value (Offffffffh) is not valid so the user must select and 
enter the correct value in answer to this question, or 
reset-into-monitor must be disabled. 


Figure 4-7 shows the display that appears with the following 
question. 


Default stack pointer for background? Offffffffh (<addr>) 


_ f (. j ..A\ 

Default stack pointer 


This value is used to exit the monitor when the background monitor 
is entered from reset. If the default value, OFFFFFFFFH is invalid, so 
the user should either disable reset into monitor, or enter the correct 
value of the default stack pointer. 


STATUS: Configuring M68030_. . .. 

Default stack pointer for background? OffffffffH 

Addr RECALL 


Figure 4-7. Default Stk Pointer for Background Display 
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Select To Block ECS, 
OCS Signals During 
Background Monitor 
Cycles 



Figure 4-8 shows the display that appears with the following 
question. 

Block ECS, OCS signals during background monitor cycles? yes 
(no) 

yes Causes the ECS and OCS signals to be blocked to the 
target system during background monitor execution. 

no Causes the ECS and OCS signals to be unblocked 

to the target system during background monitor 
execution. This causes the processor to look as 
though it is executing out of cache. 




ECS, OCS signals blocked 


During background monitor execution, these signals will be blocked to the 
target system. 

ECS, OCS signals not blocked 


ECS and OCS signals will be visible during background monitor execution. 
This will cause the processor to look as though it is executing out of 
cache. 


STATUS: Configuring M68030... 

ECS, OCS signals during background monitor cycles? yes 

yes no RECALL 


Figure 4-8. Block ECS, OCS During Background Monitor 
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This question determines whether keepalive cycles are generated 
during background monitor execution. The keepalive function 
causes a read cycle, at a specified address, to happen periodically. 
Some target systems need to see continuous cycles. When the 
background monitor is executing, AS, DS, and DBEN signals are 
blocked. Figure 4-9 shows the display that appears w ; ih the 
following question. 


If you answer no to this question, the next question will be not be 
asked. 


Perform periodic foreground accesses while in monitor? no (yes) 

Perform periodic foreground accesses while in monitor 


Answering yes will cause the background monitor to periodically 
access an address in foreground space. This is useful for triggering 
memory refresh strobes in the target, etc. 


STATUS: Configuring H68030.. 

Perform periodic foreground accesses while in monitor no 

yes no RECALL 


Select To Perform 
Periodic Foreground 
Accesses 


Note 


4 


Figure 4-9. Foreground Accesses in Monitor Display 
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Selecting Address for Figure 4-10 shows the display that appears with the following 

Periodic Foreground question. 

Access 

Note « if you answer no to the previous question, thus question will be not 
" be asked. 


Address for periodic foreground access? 0 (<addr>) 



Figure 4-10. Address for Foreground Access Display 
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Enabling The This question allows you to choose whether or not to use the 

Foreground Monitor foreground monitor. The foreground monitor may be loaded by 

the background monitor. If you choose to use the foreground 
monitor, only the load memory command (of all the commands 
that require the monitor) is allowed. The foreground monitor can 
operate without disabling any interrupts, and it allows full user 
defined coprocessor support. However, the foreground monitor 
takes up target resources, and does not allow physical memory 
access when the MMU has been configured to be enabled. Figure 
4-11 shows the display that appears with the following question. If 
this question is answered no, the sequence will skip to the "Modify 
memory configuration?" question. 

Enable foreground monitor? no (yes) 


Foreground monitor enabled 

The user may load a foreground monitor to provide functionality. This 
monitor may be loaded using the background monitor. Other than the 
memory access for the load, no commands requiring monitor functionality 
are allowed until the foreground monitor has been loaded. The foreground 
monitor can run without disabling interrupts and also allows the emulator 
to support user-defined coprocessor registers access. A foreground 
monitor takes up target system resources and will not support physical 
memory access when the MMU is enabled in configuration. 

Foreground monitor disabled 


The background monitor will be used for all monitor functionality. 

Generic coprocessor register access is not supported and interrupts are 
blocked during the monitor execution. Both logical and physical memory 
accesses are supported and target resources are not used. 

STATUS: Configuring M68030.. 

Enable foreground monitor? no 

yes no RECALL 


Figure 4-11. Enable Foreground Monitor Display 
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Interlock or Provide 
Termination for the 
Foreground Monitor 


This question allows you to determine whether the foreground 
monitor CPU space cycles will be terminated immediately as an 
asynchronous cycle or if the cycles will be interlocked with the 
target system cycles. 


Figure 4-12 shows the display that appears with the following 
question. 

Interlock or provide termination for foreground? terminate 

(intrlck) 


Interlock foreground cycles 


Foreground monitor CPU Space cycles will be interlocked with the 
target cycles, as determined by the map entry for the foreground 
address space. 

Emulator terminates foreground cycles 


The cycle is terminated immediately as an asynchronous cycle. 


STATUS: Configuring M68030.. 

Interlock or provide termination for foreground? terminate 

intrlck term RECALL 


Figure 4-12. Interlock or Terminate Foreground Display 
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Using Custom 
Coprocessors 


Note 



Custom register access is only supported with the foreground 
monitor enabled, except in the case of the MMU registers. MMU 
registers display and modification are supported for both 
foreground and background monitors. 


The 68030 emulator has the capability to access floating point 
processors, memory management units, and other coprocessors in 
your target system. You can both display and modify coprocessor 
register sets. In order to use custom coprocessors with the 
emulator, you must provide a custom register format file defining 
the coprocessor register set and modify the emulation monitor 
program as described in chapter 8 of this manual. This must be 
done prior to modifying the emulation configuration. 

Figure 4-13 shows the display that appears with the following 
question. 

Any custom registers? no (yes) 

yes The emulator is enabled to access the 

custom coprocessors that you have defined 
in you custom register format file. 

no Use of custom coprocessors is disabled. 
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Custom coprocessor support 


This question should be answered "yes” is it is desired to access 
coprocessor register sets, such as an external FPU. The user is 
expected to supply monitor code to read and write register contents. 


STATUS: Configuring M68030 

Any custom registers? no 


yes no 


RECALL 


Figure 4-13. Any Custom Registers Display 
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Specifying The 
Custom Coprocessor 
File 


Note 



If you answered yes to the question "Any custom registers?", the 
following question will be displayed on your screen. 


Figure 4-14 shows the display that appears with the following 
question. 

Name of custom register format file? (<F1LE>) 

The default answer to the question is NULL. The MMU is 
supported internally. There is an example custom register format 
file provided with your emulation software. The example is located 
at /usr/hp64000/inst/emul32/0410/0204/custom_spec. If you are 
using custom coprocessors, you must enter the full pathname of 
the custom register format file that you made for these 
coprocessors. 
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Custom register format file 


This file supplies the format specification for the custom 
register sets that are enabled. Information about the register 
sets is present including the display format. The MMU is 
excepted from needing this formatting data. 


STATUS: Configuring M68030_ 

Name of custom register format file? 

FILE RECALL 


Figure 4-14. Name of Custom Reg. Format File Display 


Modifying a Memory When you begin your initial emulation session you must configure 
Configuration (map) the memory space you will be using. The configuration you 
need is based on your user program requirements and on the 
configuration of your target system, if one is available. As you 
progress with your program development, your memory map 
requirements will probably change. As your requirements change, 
you will need to modify your configuration file. 

The following questions let you review and modify the memory 
configuration stored in the emulation configuration file. 
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Note ^ 


If you answer no to the "Modify memory configuration?" question, 
the sequence will skip to the "Modify emulator pod configuration?" 
question. 


Modify memory configuration? no (ves) 

yes Allows memory mapping and deMMUer configuration to 
be modified. The current memory map is displayed. 
Memory configuration is explained in the following 
sections. 

no Allows you to skip memory configuration if you do not 
want to change memory usage. A no response causes the 
memory to be configured as specified by the current 
emulation configuration file. If no is entered, the next 
question is "Modify emulator pod configuration?" 


Break processor on write to ROM? yes (no) 

yes A break to the emulation monitor occurs if the processor 
attempts to write to a memory location mapped as 
emulation or target ROM. 

no Breaks are not generated when the processor attempts to 
write to memory locations mapped as emulation ROM. 


If write operations to emulation memory mapped as ROM are 
attempted during program execution, the contents of emulation 
memory are not modified. Write operations resulting from 
emulator commands that modify memory (e.g., load and modify) 
will modify the contents of emulation memory locations mapped as 
ROM if the MMU is disabled or it is a physical access. 

Write operations to target memory mapped as ROM may or may 
not alter memory contents, depending on your target system 
hardware. 
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Selecting to Block 
BERR on 
Non-interlocked 
Emulation Memory 


Figure 4-15 shows the display that appears with the following 
question. 


Block BERR on non-interlocked emulation memory? no (yes) 


yes Bus errors (BERR) that occur during emulation memory 
cycles (if the address is configured as non-interlocked) are 
blocked. This allows the monitor or other user program to 
run in a memory space not usually allowed by the target 
system hardware. This does not prevent retry operations 
from happening. 




BERR disabled 


Bus errors (BERR) that occur during emulation memory cycles when 
the emulation memory address is configured as non-interlocked 
will be blocked. This allows the monitor or other user programs 
to run in a memory space not normally allowed by the target 
system hardware. The BERR signal is not blocked if it is part 
of a retry operation. 

BERR enabled 


All bus error signals not excluded by a unique mapping are admitted to 
the processor. 


STATUS: Configuring M68030.. 

Block BERR on non-interlocked emulation memory? no 

yes no RECALL 


Figure 4-15. Block BERR on Non-interlock Em Mem Display 
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STATUS: 


no All bus error signals (BERR) are transmitted to the 
processor. 

Mapping Memory 

After you answer the question "Break processor on write to 
ROM?”, the emulation memory map is displayed. The 68030 
processor memory space required for your applications must be 
mapped to emulation memory, target memory, or guarded 
memory. Emulation memory is memory that is physically located in 
the emulation pod. Target memory is memory that is physically 
located in your target system. Memory mapped as guarded is 
memory that, under normal conditions, should not be accessed by 
your target system. Any reference to the address space mapped as 
guarded memory will result in an emulation memory break and the 
display of the following error message: 


68030—Running in monitor Guarded access a= <ADDR> (<FC>) 


where <FC> is a two letter mnemonic describing the 
function code of <ADDR>. 

The memory mapper must be properly programmed to correspond 
to emulation memory and target system memory resources in 
order for emulation to work correctly. The memory mapper allows 
you to divide the processor’s address space into blocks that can be 
individually configured to have any of the following attributes: 

B Emulation memory; RAM or ROM; synchronous; 
interlocked; or asynchronous with 8-bit, 16-bit, or 32-bit 
width;. 

■ Target memory; RAM or ROM; bus error blocked; cache 
disabled; burst mode blocked. 

■ Guarded memory. 
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During emulation, the memory mapper monitors the address bus 
and provides the attributes for the address present at any given 
time. This information is used by the emulator hardware to control 
the flow of data between the emulation processor and the memory 
resources. 

Memory Map Display Organization. The default memory map 
display is shown in figure 4-16. Each entry line shows the entry 
number, address range starting value, address range ending value, 
function code of the address range, attributes of the entry, and 
overlay definition. The overlay definition shows the number of the 
entry being overlaid, and the address in the memory map entry 
being overlaid that corresponds to the starting address of the 
overlay entry. 


Mapping 

memory: 

Function codes = OFF 


ENTRY 

START 

END 

ATTRIBUTES 

OVERLAY 

1 

OH 

FFFFFFFFH 

TARGET RAM 



STATUS: Mapping emulation memory, default mapping: guarded_. . .R. . . . 

end 

map map_over modify delete display deMMUer end 


Figure 4-16. Default Memory Map Display 
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Softkey labels are displayed for the commands available in the 
memorymapper. You can specify individual map entries, overlay 
existing map entries, modify existing entries (including the default 
mapping attributes), modify the deMMUer configuration, delete 
currently defined entries, or end the map definition session. These 
commands are described in the following sections. 

Memory Map Definition. The memory map partitions the 
processor address range into blocks defined as emulation RAM or 
ROM, target RAM or ROM, or guarded (illegal) space. Each entry 
defines a particular address range as one of the five possible 
memory types. 

Memory entries can be further defined by function code. 

Emulation memory can also be assigned cycle type of synchronous, 
interlocked, or asynchronous with a bit-width of 8,16, or 32. Based 
on the cycle type, emulation memory returns the appropriate 
signals to the 68030 processor. 

Any address range not defined by an entry is mapped to the 
memory default. The addresses entered are physical addresses at 
the appropriate 68030 pins. 

The memory mapper has a resolution of 256 (ffH) bytes. Once the 
mapper software processes the inputs, the entry range is rounded 
to integral multiples of 256 bytes. The final range includes all of 
the specified memory space, plus the remainder of any 256-byte 
blocks which were partially specified. Any parts of the 68030 
address range not defined by an entry are mapped to the memory 
default. 
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Note Vk If the end address of a specified address range is the same as the 

^ first address of a 256-byte memory block (e.g. lOOh, xxxxxxOOh, etc), 
the end address value is rounded down one byte (e.g. to Offh, 
xxxxxxffh, etc.) 

This can cause a problem if you attempt to specify an address range 
with the same start and end address corresponding to the first 
address of a 256-byte memory block. If your enter the command: 
map lOOh thru lOOh emulation ram Return 
the error message ’’ERROR: Lower address in range greater than 
upper address” is displayed. This command is not allowed by the 
emulator because the ending address (when rounded down to Offh) 
is less than the starting address (lOOh). 


All emulation memory is displayed and loaded directly by the 
emulation software by way of the memory port assigned to the host 
processor. If the MMU is enabled, logical addresses are done using 
the emulation monitor. Physical addresses are still done using the 
host port. Any attempt by the 68030 CPU to write to memory 
mapped as emulation ROM will not change the contents of that 
memory location. 

When target memory is specified for a given address range, all 
memory cycles using that address range access the target system. 
All memory load and display operations for your target system are 
done via the emulation monitor. 

Multiple processor address ranges can be overlaid onto the same 
physical emulation memory by using the map overlay command. 
Overlaying applies only to emulation memory. The emulator has 
no control over your target system memory resources. 

Emulation Monitor Program Memory Requirements. You 

need to know certain information about the emulation monitor 
(delivered as part of your emulator software package) prior to 
linking the monitor program and mapping memory space. Chapter 
7 gives a detailed description of the emulation monitor, including 
memory requirements for the program. Refer to the paragraphs 
titled ’’Emulation Monitor Memory Requirements" in chapter 7 for 
a full description of the emulation monitor memory requirements. 


Configuring The Emulator 4-29 



Using The Map Command 


All memory map entries are made up of an address range and 
attributes which specify the type of memory accessed by the 
specified address range. In addition, a specific function code and 
address width (port size) can be assigned to a memory map entry. 
Memory mapping is done using the map command. 

Mapper blocks are entered using the following command syntax: 


q mop y 


G 




"A 

fcode 

<F_C0DE> 

h 



J 


<ADDR> 


thru 


X 


<ADDR> 


>) d 


<RETURN> 


torget —-Q 


emulation 


'° n ^ \— rqm y 


synchronous ^ - 

K-^ ^asynchornous^ )-^— width 8 


-A 


JN 


width 16^ 




width 32^ 
interlocked^-^ 


X 


burst 


guarded y- 


cache_dis 


berr_en 


where: 

fcode lets you assign a function code to a memory map entry. 
The function codes enabled for your particular 
configuration are displayed on softkeys after you press 
the fcode key. If you specify modify defined_codes 
none^ the fcode attribute is disabled and the softkey is 
not displayed. You can specify user-defined function 
codes by typing in the numeric value of the function. 
See the section in this chapter on the modify 
defined_codes command for more information on 
function codes. 
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<ADDR> defines a bit pattern of up to 32 bits which specifies a 
particular location in memory. That bit pattern can be 
entered as a binary, octal, hexadecimal, or decimal 
number. 


guarded 


emulation 

rom 


ram 


inter¬ 

locked 

synch¬ 

ronous 

asynch¬ 

ronous 

width8 

widthlb 

width32 


designates an address range which is not expected to be 
accessed. Any processor access to a location within 
such a range will result in a break of the program 
execution. No emulation memory is used when an 
address range is specified as guarded. 

designates memory supplied by the emulation system. 

designates memory which cannot be modified by the 
68030 processor. Emulation memory that is actually 
RAM but is mapped as ROM performs as ROM 
during emulation. The host can read and write to 
ROM. 

designates memory which can be read from or written 
to without restriction. 

designates that the memory entry is defined to 
interlock cycles with your target system. 

designates that the memory entry is defined for 
synchronous cycle access. 

designates that the memory entry is defined for 
asynchronous cycle access. 

defines the memory map entry to be an 8-bit data port, 
defines the memory map entry to be a 16-bit data port, 
defines the memory map entry to be a 32-bit data port. 


target designates memory supplied by your target system. 

Mapping an address range to target space requires no 
emulation memory. 
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burst enables the burst mode access. 
cache_dis disables caching for address range. 

berr_en enables bus errors for the entry. 

The first < ADDR> of a range specification should be the starting 
address of a block boundary. If an address inside a memory block 
area is entered, the system converts this address to the starting 
address of the block prior to its mapping. Leading zeros may be 
deleted as long as the most significant digit is numeric. 

The minimum map entry size is 256 bytes. The maximum size is the 
number of available blocks. 

Using The Map_overlay Command 

When making a memory map, you can enter "overlay" addresses in 
emulation memory hardware blocks. With this feature, you can 
cause a single block to function as if it were several different 
blocks, each corresponding to a different set of addresses. Memory 
overlaying applies only to emulation memory. The emulator has no 
control over target system resources. 

Map overlays are entered using the following command syntax: 


C m °p_ over| °y)~ 


» ) <ADDR;X thru <addr> 1 - T mm y 


fcode y> <F_CODE> 




fcode <F_CODeT 


<ADDR>~| -» |<RETURN>| 


Map_overlay command parameters have the same definitions as 
those listed for the map command parameters. 

There are some restrictions imposed on the map overlay function 
by the physical structure of emulation memory. Emulation memory 
is physically made up of 4K byte blocks of memory as shown in 
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figure 4-17. The memory mapper hardware has a resolution of 256 
bytes, the minimum map entry size. 

When specifying a memory address, the two least significant digits 
in a hexadecimal address (see figure 4-18) specify the address 
within the 256 byte entry. The third least significant digit specifies 
one of the 16 256-byte entries within the 4K byte physical memory 
block. 


4K BYTE 

MEMORY 

BLOCK 


PHYSICAL 


OVERLAY 

BLOCK 


ADDRESS 

0 

} 256 BYTES 

0 

1 

VALID OVERLAY 


1 






z 



3 




• 



• 

• 



• 

• 

ILLEGAL OVERLAY 


• 

n 


r h 

O 



D 


D 

E 


E 

F 


F 


Address of overloy and address to be overlaid must be 
mapped to the same 256 byte block. 


Figure 4-17. Overlay Addressing Within Physical Blocks 


XXXXX YZZ 


Address Location within 256 Byte Block 


Location of 256 Byte Block within 
4 K Physical Memory Block 


Address of 4K Physical Memory Block 


Figure 4-18. Hexadecimal Address Bit Definition 


Configuring The Emulator 4-33 




When overlaying memory, the address of the memory overlay and 
the address of the memory location must be mapped to the same 
256 byte block in the 4K byte physical memory block, e.g., the third 
least significant hexadecimal digit in the specified addresses must 
be identical. For example, the command: 

map_overlay fcode SUPER_DATA0f00f800h thru 
0f00f8ffh rom over fcode SUPER_PROG 
0002800h Return 

is a valid command. However the command: 

map_over!ay fcode SUPER_DATA0f00f800h thru 
0f00f8ffh rom over fcode SUPER_PROG 0002a00h 
Return 

is not a valid command. An attempt to execute the last command 
would cause the error message ’’Offset for overlay does not match 
emulation address” to be displayed. 

Memory Mapping Example 

The following example shows how to map memory in a system 
made up of a target system with some memory installed and the 
68030 emulator. This example shows how to use the map and 
map_overlay commands. Before defining the new memory map, 
delete all entries in the current map. Enter the following 
commands: 

delete all Return 

modify defined_codes all Return 

The memory map display will appear as shown in figure 4-19. Note 
that one entry is still displayed. The CPU_SPACE mapping to 
target RAM cannot be deleted by the user. This address space is 
required for vectored exception processing. 
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Mapping memory: 
ENTRY START 
1 OH 


Function codes = ON 

END FC ATTRIBUTES 

FFFFFFFFH (CS) TARGET RAM 


OVERLAY 


STATUS: Mapping emulation memory, default mapping: guarded_. . .R. . . . 

modify defined_codes all 


map map_over modify delete 


display deMMUer end 


Figure 4-19. Sample Overlay Mapping #1 


CPU_SPACE must be mapped to target memory so that vectored 
exceptions will not interfere with emulation functions. 

Type the following entries into the memory map. 

map fcode USERJDATA 0 thru Offffh emulation ram 
asynchronous width32 Return 

map fcode USERJPROG 18000000h thru 1800ffffh 
emulation rom asynchronous width32 Return 

map fcode SUPER_DATA 0 thru 3ffh target rom burst 
cache_dis berr_en Return 
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map fcode SUPER_PROG 0 thru 3ffh target rom burst 
cache_dis berr_en Return 




The memory map resulting from these commands is shown in 
figure 4-20. 


map fcode SUPER_PROG OfOOOOOOh thruOfOOOfffh 
emulation ram asynchronous width32 Return 

map_overlay fcode SUPER_DATA OfOOOOOOh thruOfOOOfffh 
ram over fcode SUPER_PROG OfOOOOOOh Return 


Mapping memory: 

Function codes = 

ON 


ENTRY 

START 

END 

FC 

ATTRIBUTES 

OVERLAY 

1 

OH 

FFFFH 

(UD) 

EMUL RAM [32 bits] 


2 

18000000H 

1800FFFFH 

(UP) 

EMUL ROM [32 bits] 


3 

OH 

3FFH 

(SD) 

TARGET ROM [burst/berr] 


4 

F000000H 

F000FFFH 

(SD) 

EMUL RAM [32 bits] 

F000000H (6) 

5 

OH 

3FFH 

(SP) 

TARGET ROM [burst/berr] 


6 

F000000H 

F000FFFH 

(SP) 

EMUL RAM [32 bits] 

F000000H 

7 

OH 

FFFFFFFFH 

(CS) 

TARGET RAM 


STATUS 

: Mapping 

emulation 

memory 

, default mapping: guarded 

. . .R_ 

map_overlay fcode SUPER_ 

DATA OfOOOOOOh thru OfOOOfffh ram 

over fcode SUPER 

PROG 

OfOOOOOOh 





map 

map_over 

modify 

delete 

display deMMUer 

end 


Figure 4-20. Sample Overlay Mapping #2 
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The entries in the memory map correspond to the following 
address spaces: 

1. User application data space 

2. User application program space 

3. Exception vector table space 

4. Emulation monitor data space 

5. Exception vector table space 

6. Emulation monitor program space 

7. CPU SPACE 

The emulation monitor data space (entry 4) has been overlaid onto 
the emulation monitor program space, This enables the 68030 
processor to access data locations in the emulation monitor. The 
overlay is indicated in the OVERLAY column of the memory map 
display for entry 4. The "(6)" indicates that entry 4 is overlaid onto 
entry 6. The address fOOOOOOH is the address in entry 6 that 
corresponds to the starting address of entry 4. This memory map 
shows you a typical 68030 memory map. 

Using The Modify Command 

The modify command lets you modify the memory map. The 
modify defined codes command lets you selectively enable or 
disable the 68030 function code signals (FC0 through FC2). The 
modify < ENTRY > command lets you modify the range, 
attributes, fcode, and overlay parameters of a memory map entry. 
The modify default command lets you change the default memory 
parameters. 

Modify Defined_Codes. The modify defined_codes command 
lets you selectively enable or disable the 68030 function code 
signals. The command syntax is shown in the following diagram: 


modify j —*{ defined-Codes^ )-^-— all ^ 



none 



<RETURN> 
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where: 


all enables the memory mapper to use all three function 

code lines (FCO through FC2) in mapping memory. If 
all is selected, you can specify any of the eight function 
code states except CPUSPACE. The function codes 
SUPER_PROG, S' T R_DATA, USER_PROG, 
AND USER DATA can be entered from softkeys. 

The remaining function codes must be entered as 
numeric values. Function code 3 is user definable. 
Function codes 0 and 4 are reserved for use by the 
processor manufacturer. Function code 7 specifies 
CPU address space. If you enter fcode 3, USER_RSVD 
is displayed in the FUNCTION CODES column of the 
memory display. If you enter fcode 0 or 4, MOT_RSVD 
is displayed in the FUNCTION CODES column. 

none disables all three function code lines, when none is 
selected, the emulator memory mapper ignores the 
function code lines and monitors only the 32-bit 
address bus during emulation. With none selected, the 
fcode parameters are not available in the emulation 
commands. The FUNCTION CODES column is 
deleted from the memory map display. 
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Modify < ENTRY >. The modify < ENTRY> command lets you 
modify the range, attributes, fcode, and overlay parameters of a 
existing memory map entry. The command syntax is shown in the 
following diagram: 


—modify <ENTRY> 




c 


<RETURN> 


K_ range ^-4 <ADDR> 




burst 


guarded^- 


(code )— <F_CODE> 


overlay remove ^ 



^ attributes' -^-— emulation^ Hs-— ram J - 


thru 


IH 


<ADDR> 


— ^ synchronous^ )- 

K- ^osynchronous^ sr— width 8 ^ -4 


target ^ rom 


K 


width 16 


interlocked ; 


width 32 V 



cache_dis 



berr_en 




fcode 


>[ 


<F_CODE> 


<ADDR> 


where: 

range lets you specify a new range for the memory map entry 
(<ADDR> thru <ADDR>). 

attributes lets you change the entry to: 

emulation memory, RAM or ROM, interlocked, 
synchronous, asynchronous with a data port width 
of 8-bits, 16-bits, or 32 bits 

target memory, RAM or ROM, bus error blocked, 
cache disabled, burst mode blocked 

guarded 
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fcode lets you modify the function code address mapping for 
the entry. The selections available to you depend the 
definition of the defined_codes parameter. 

overlay lets you remove an overlay from an entry, e.g., the 
entry is converted to the physical address 
corresponding to address specified in the entry, or it 
lets you change the function code or address range of 
the address space being overlaid. 

Modify Default. Any address ranges which are not mapped when 
the mapping session is terminated are assigned the memory 
attribute specified as the default. The default attribute can be set 
up to be target RAM, target ROM, or guarded by using the modify 
default command. Initially, the system assigns all unmapped 
memory to guarded memory. The command syntax is shown in the 
following diagram: 


( modifyy-»^defoult 


\ target J- 


^uorded^)- 



<RETURN> 


where: 

target designates memory supplied by your target system. 

When default is mapped to target, the attributes are 
set to: caches enabled, burst enabled, and BERR 
enabled. 

guarded designates an address range which is not expected to be 
accessed. Any processor access to a location within 
such a range will result in a break of the program 
execution. 
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Deleting Memory Map Entries 

Any one or all of the memory map entries can be removed by using 
the delete command with the exception of the default 
CPU_SPACE entry. The syntax for the delete command is shown 
in the following diagram: 


Q delete 


< 011 > 


<RETURN> 


<ENTRY> 


o 


Modify the DeMMUer You can modify the DeMMUer configuration while in the "modify 
Configuration memory configuration" environment. To modify the deMMUer 
configuration you must press the deMMUer softkey. The 
configure_deMMUer label will appear on the command line. Press 
the Return key. The display will be as shown in figure 4-21. The 
deMMUer is described in some detail in chapter 5 and fully in the 
68030 Internal Analysis User’s Guide. 
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deMMUer configuration 

deMMUer hardware disabled 

Translation Control - 0000000.0H 

<e sre fcl ps is tia tib tic tid> 

0 0 0 - 0 

Virtual Address start - 00000000H 

Root Descriptor Type -Invalid Descriptor 


Range List - 
A 
B 
C 
D 


Start End 

undefined range 
undefined range 
undefined range 
undefined range 


STATUS: Configuring DeMMUer 

configure_deMMUer 


.R. . . . 


range enable disable set 


display return 


Figure 4-21. Modify DeMMUer Configuration Display 


Ending The Mapping Session 

The memory map configuration session is exited by pressing the 
endsoftkey followed by Return. 
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Modifying The 
Emulation Pod 
Configuration 

Note 


Configuring for 
In-circuit Emulation 
Session 

Note 4 


The following question asks you whether or not you want to modify 
the current emulation pod configuration. 


If you answer no to the "Modify emulator pod configuration?" 
question, the sequence will skip to the "Modify simulated I/O 
configuration?" question. 


Modify emulator pod configuration? no (yes) 

no The emulation pod configuration questions are skipped 
and the emulation module uses the current pod 
configuration. The emulator will skip to the "Modify 
simulated I/O configuration?" question. The default pod 
configuration is as follows: 


In-circuit emulation session? 

no 

Disable on-chip cache 

yes 

MMU enabled during session 

no 


yes You must answer the following emulator pod 

configuration questions in order to reconfigure the 
emulator pod. 


Figure 4-22 shows the display that appears with the following 
question. 


If you answer no to the "In-circuit emulation session?" question, 
the sequence will skip to the "Disable on-chip cache?" question. 
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In-circuit emulation session 


The emulator may be adjusted to the target system by controlling 
DMA and the processor clock rate. 

Out of circuit emulation session 


The clock rate is locked at 20 MHz. 


STATUS: Configuring M68030 emulator pod.. 

In-circuit emulation session? no 

yes no RECALL 


Figure 4-22. Configuring for In-circuit Emul. Display 


In-circuit emulation session? no (yes) 

no The emulator is configured out-of-circuit. As such the 
clock rate is set to 20MHz. This question has no other 
action than to control whether clock or DMA questions 
are asked next. The question does not force the emulator 
to be used either in or out of circuit. 

yes The emulator is configured in-circuit, operating with 

target hardware. As such the emulator may be adjusted to 
the target system by controlling the DMA and clock rate. 
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Enabling DMA 
Transfers 


Figure 4-23 shows the display that appears with the following 
question. 


Note 


If you answer no to the "Enable DMA transfers?" question, the 
sequence will skip to the "CPU clock rate faster than 25 MHz?" 
question. 


Enable DMA transfers? no (yes) 


DMA transfers enabled 


Bus requests will be admitted to the processor. If the AS, address, 
and data lines are active at the processor pins during the DMA cycles, 
the analyzer will capture those states. 

DMA transfers disabled 


Bus requests are blocked to the processor. 


STATUS: Configuring M6 8030 emulator pod.. 

Enable DMA transfers? no 

yes no RECALL 


Figure 4-23. Enable DMA Transfers Display 
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no Bus requests are blocked to the processor. The processor 
ignores the BR and BGACK input signals and does not 
respond with BG. 

yes Bus requests are admitted to the processor. If the AS, 
address, and data lines are active at the processor pins 
during DMA cycles, the analyzer will capture those states. 
The processor responds normally to the assertion of the 
BR (Bus Request) and BGACK (Bus Grant 
Acknowledge) signals. 


Enabling DMA 
Transfers Into 
Emulation Memory 


Note 



If you answered no to the previous question, this question is not 
displayed on your screen. 


Enable DMA transfers into emulation memory? no (yes) 

no DMA transfers to memory addresses mapped as emulation 
memory are disabled. 

yes DMA transfers to memory addresses mapped as emulation 
memory are enabled. The DMA device must generate all 
required control signals (AS, DS, R/W, SIZ, etc.) and meet 
the 68030 timing specifications. 


CPU Clock Rate 
Determination of Wait 
States 


Figure 4-24 shows the display that appears with the following 
question. 


CPU clock rate faster than 25 MHz? no (yes) 
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CPU clock rate 


If the external clock rate is greater than 25 MHz, six wait states will be 
added to emulation memory accesses. If the external clock speed is less 
than or equal to 25 MHz, four wait states will be added for emulation memory 
accesses. 


STATUS: Configuring M68030 emulator pod 

CPU clock rate faster than 25MHz? no 


yes no RECALL 


Figure 4-24. CPU Clock Rate Display 


no If the clock rate is less than or equal to 25.0MHz, all 

emulation memory accesses will occur with four wait states. 

yes If the clock rate is greater than 25.0MHz, six wait states 
will be inserted for emulation memory and interlocked 
emulation memory accesses. 
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Disabling On-chip Figure 4-25 shows the display that appears with the following 
Cache question. 


Disable on-chip cache? yes (no) 

no If the cache is enabled by answering no to this question 
and is also enabled by the target system hardware, the 
analyzer may not show all memory accesses (the analyzer 
cannot detect cache hits). You must answer yes to this 
question in order to use all of the analysis features. 



On-chip cache disabled 


Analysis functions perform normally. 


On-chip cache enabled 


The cache may be enabled by the target. 

If this is done, then: 

* the analyzer will not be able to capture a cache hit, as 
this access is not apparent on the processor pins 

* entry into the foreground monitor causes monitor instructions 

to be stored in the cache 

STATUS: Configuring M68030 emulator pod 


Disable on-chip cache? yes 


yes no 

RECALL 




Figure 4-25. Disable On-chip Cache Display 
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yes The processor caches are enabled. A yes answer improves 
system performance but much analysis capability is lost. 

The enable (E) bits of the CPU CACR register must be set 
by the target software for the caches to be enabled. 

The 68030 has both program and data cache with separate enables 
in th CACR. Refer to chapter 6, "Target System Interface", for 
more information regarding the on-chip cache. 

Enabling MMU For Figure 4-26 shows the display that appears with the following 

Use During Emulation question. 

Session 


MMU enabled during session 


This option does not explicitly enable the MMU, but rather allows 
the target to enable the MMU. If the user intends to use the MMU 
during the emulation session, this option should be chosen. 

MMU disabled during session 


The hardware will pull on the MMUDIS line and so the MMU can not be 
enabled by the target system. Certain emulation features (e.g. 
memory access or analysis) can optimize behavior (or provide greater 
functionality) by knowing that logical addresses equal physical 
addresses. This selection will disable the deMMUer hardware. 


STATUS: Configuring M68030 emulator pod.. 

MMU enabled during session? yes 

yes no RECALL 


Figure 4-26. MMU Enabled During Session Display 


Configuring The Emulator 4-49 







MMU enabled during session? no (yes) 


Modifying Simulated 
I/O Configuration 


Modifying Simulated 
Interrupt 
Configuration 


no The emulator disables the internal MMU. 

yes If the MMU is enabled, the keywords logical and physical 
are meaningful for memory access. The deMMUer 
configuration (described during memory configuration) 
will be loaded. The target system is expected to enable the 
MMU hardware and set up all of the translation tables, 
root pointers, etc. 


The simulated I/O subsystem must be set up by answering a series 
of configuration questions. These questions deal with enabling 
simulated I/O, setting the control addresses, and defining files used 
for standard I/O. 

Modify simulated I/O configuration? no (yes) 

Answering yes to this question causes a series of simulated I/O 
questions to be asked. For information on how to answer these 
questions to configure your system, refer to chapter 9 of this 
manual. For additional information about simulated I/O, refer to 
the Simulated HO Reference Manual. 

Answering no to this question bypasses all other simulated I/O 
questions. 

Simulated interrupts are enabled by answering a series of 
configuration questions. 


Modify simulated interrupt configuration? no (yes) 

If you answer yes, the simulated interrupts questions will be asked. 
If you answer no, the questions will be skipped. Simulated 
interrupts enable you to write and test software which depends 
upon the occurrence of preemptive interrupts using an emulator 
that is out of circuit. Information describing how to configure your 
system for simulated interrupts is contained in chapter 9 of this 
manual. 
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Naming The This question lets you name an emulation configuration file 
Configuration File containing the emulation configuration information you have just 

entered. The configuration file is stored on disc and can be called 
up for use during a future emulation session. 

Configuration file name? 

Type in the filename you want and press Return. 

If you press Return without entering a name, the current 
emulation session will be configured as you specified in your 
answers and the information will be saved as the new default 
configuration of the emulator. To restore the original default file 
provided with the emulation software, you must reinitialize the 
HP 64120A Cardcage. 


Note 


If you assign a new name to the configuration file and you are using 
a command file to enter your emulation session, remember to 
modify your command file to change the name of your emulation 
configuration file (refer to the HP 64000-UXUser’s Guide for more 
information relating to command files). 


Note Vfe Emulator configuration files are slot dependent. Use of a given 
™ configuration file on one emulator and subsequent reuse on an 

emulator in another cardcage slot will result in the message "Bad 
Module File". This message indicates that the configuration file 
specified was not associated with the current emulator. The 
message is displayed as a warning only. The emulator software will 
automatically rebuild the configuration file with correct cardcage 
slot information for the current emulator. 
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DeMMUer - What It Is And How It Works 

Overview This chapter: 

■ Describes what the deMMUer is. 

■ Describes how the deMMUer operates 

■ Describes when to use the deMMUer. 

■ Describes when not to use the deMMUer. 

■ Describes the conditions under which the deMMUer will 
not perform reverse-address translations. 

■ Describes the restrictions associated with deMMUer 
operation. 

■ Describes when to start the deMMUer. 

■ Describes how to turn the deMMUer on and off. 

■ Describes the deMMUer configuration setup. 

■ Describes how to access the deMMUer configuration 
display. 
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Introduction You will need to read this chapter only if you are using the MMU 

of the 68030 and your internal analyzer is operating from input 
supplied by a deMMUer board. If you are not using the 68030 
MMU active mode, no address translations occur, and you can 
ignore this chapter. 


Note 


For more specific information on the deMMUer, refer to the 68030 
Internal Analyzer Users Guide , especially for detailed instructions 
on how to set up the deMMUer. 


What The 
DeMMUer Is 


The DeMMUer consists of hardware and software that is used to 
facilitate the display of trace data when the 68030 MMU is active. 
Without the DeMMUer, the analyzer only has access to the 
physical bus, so only physical addresses (that is; no symbols, source 
reference, etc.) would be displayed. The deMMUer tracks MMU 
table walks to get the latest logical-to-physical translation 
information. As a result, the deMMUer is able to effectively 
translate the physical address information to logical. This allows 
the analysis display software to perform symbol lookups on the 
addresses (as well as source referencing). 


How The 

DeMMUer 

Operates 


The on-chip Memory Management Unit (MMU) of the 68030 
translates logical (virtual) addresses to physical addresses that are 
placed on the processor address bus. The deMMUer translates the 
physical addresses back to logical addresses in real-time. The 
deMMUer tracks only the physical addresses in the ranges 
specified in the deMMUer configuration display. 
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The physical address from the 68030 MMU is supplied as an input 
to the deMMUer. The deMMUer contains a set of translation 
tables like those in the 68030 MMU. The deMMUer translation 
tables provide the reverse function of the translation tables in the 
MMU (given a physical address, they look up the logical address 
from which it was derived). The deMMUer outputs the logical 
address corresponding to the physical address from the 68030 
MMU. 

Each time the 68030 MMU performs a table search, the deMMUer 
detects the event and follows MMU activity to build a 
corresponding set of tables for its reverse-address translations. 

If you have the deMMUer running from the time you start the 
68030 MMU, the deMMUer will have current translations to 
reverse each of the translations performed by the MMU. 


Be sure to flush the address translation cache (ATC) of the MMU 
before enabling the MMU. Otherwise, out-of-date translations 
(logical to physical) may reside in the ATC. There is no facility in 
the 68030 emulator/analyzer to flush the ATC. You can include an 
option to the command that loads the TC register or loads the root 
pointer to ensure that the ATC is flushed after reset. 


For addresses for which the deMMUer has no translation, it 
supplies the physical address that was output by the 68030 MMU, 
and tags it as being a physical address. The analyzer will show this 
address in its trace list, but it will not be able to show any symbol 
associated with this address, nor will it be able to recognize any 
trace commands occurring on this address if those commands are 
specified using source-file symbols. 
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When To Use The 
DeMMUer 


You need to use the deMMUer when the 68030 MMU is active, 
and you want to use any of the following features during analysis of 
a program: 

1. You want the trace list to show the assembly language 
form of the activity it captured during a trace. The inverse 
assembler requires sequential logical addresses in order to 
look up the next piece of program information. Physical 
addresses will probably be non-sequential when crossing a 
page boundary. 


2. You want to enter a trace specification that will be met 
when a certain source-file event appears during a trace. 

To do this, you enter the name of the source-file symbol 
that identifies that event. Basic trigger/store/count 
features are not supported for code in physical addresses. 
The symbols in a file are always logical. In a dynamic 
environment, the relationship between an instruction or 
data location and its physical address may not be constant 
throughout the running of a program. 

3. You want the trace list to show address values in terms of 
the symbol names assigned in the source files. Symbol and 
source line referencing operates on the fact that a symbol 
or source line resides at a particular logical address. That 
relationship is established with the language tools. The 
source referencing has no knowledge of physical addresses. 


4. You want to perform high-level analysis on the program 
you are developing by using such tools as the HP Software 
Performance Measurement Tool (SPMT). High-level 
analysis tools, such as SPMT, gather data based on logical 
address information. These tools have no facilities for 
performing physical-to-logical address translations. 
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When To Turn Off 
The DeMMUer 


Turn off the deMMUer when you want to trace activity that shows 
the addresses within physical memory. This information may be 
useful when you are analyzing the behavior of your operating 
system. 


Under What 
Conditions The 
DeMMUer Will Not 
Perform 

Reverse-Address 

Translations 


There are two conditions under which the deMMUer will not 
perform reverse-address translations: 

1. If the root pointers use page descriptor DT fields. In this 
case, no table searches will occur. Physical addresses will 
equal logical addresses plus the offset specified in the root 
pointer. 

2. If the two root pointer Descriptor Type (DT) fields are 
different types (for example, one short and the other long), 
and both root pointers are used, the deMMUer will fail to 
work because the deMMUer has facilities for only one 
root-pointer definition. Refer to how to select a root 
pointer descriptor type in the 68030 Internal Analyzer 
User’s Guide for suggestions of how to handle this problem. 
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When To Start The 
DeMMUer 


Startup With The 
Emulator 


The Emulator Was 
Running Without 
Using The DeMMUer, 
And Now I Want To 
Use It 


You can start the deMMUer at the same time as the 68030 MMU 
starts, or you can turn on the deMMUer after the MMU has been 
operating. Each case is discussed in the following paragraphs: 


The best time to start the deMMUer is just before beginning a run 
of program. The deMMUer flushes its reverse translations as part 
of the processor reset procedure. This ensures that the translation 
tables within the deMMUer contain no old translations. Then the 
deMMUer waits to detect the first table search performed by the 
68030 processor. Logical address information is available 
immediately after reset. All table searches are monitored, keeping 
the deMMUer physical-to-logical address translations up to date. 


If the deMMUer was configured and enabled properly prior to 
running your program, the deMMuer may be turned on (by 
configuration or by the set analysis mode logical command) later, 
and will contain the current reverse translations. 
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There are two ways to turn on and turn off the deMMUer: one is by 
setting the analysis mode, and the other is by invoking the 
emulation configuration set of questions. Each is described below. 


Note ttft You may turn on the deMMUer and still have only physical 
™ address information. The deMMUer can only supply logical 

address information after you have (1) enabled the MMU of the 
68030 processor, (2) set up a valid deMMUer configuration, and 
(3) enabled the deMMUer. The way to set up the deMMUer 
configuration display and enable the deMMUer is discussed in the 
68030 Internal Analyzer User's Guide 

You will always have logical addresses when the 68030 MMU is off. 


Invoke the emulation configuration questions by using the modify 
configuration command. Proceed through the questions until the 
following configuration question can be answered, then answer it 
yes: 

Modify memory configuration? 

In the memory mapping display, enter the following command: 

configure_deMMUer 

In the deMMUer configuration display, enter the following 
command: 

enable_deMMUer 

Even though you have activated the deMMUer, it will still provide 
physical address information for analysis until it has been loaded 
with a valid configuration. 

Once turned on, the deMMUer will track the MMU activity, and 
update its translation tables each time the MMU makes a change 
to its translation tables. Note that the MMU is turned on or off by 


Turn On/Off By Using 
Emulation 
Configuration 
Questions 


How To Turn On 
And Turn Off The 
DeMMUer 
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Turn On/Off By 
Setting The Analysis 
Mode 


DeMMUer 

Configuration 

Setup 


another emulation configuration question that appears after the 
memory mapping display: 

"MMU enabled during session? yes” 

disable_deMMUer 

This turns off the deMMUer. Only physical addresses will be 
supplied to the analyzer. Therefore, only the physical analysis 
mode will be available. 

If you have the 68030 MMU enabled, and you have a valid value in 
the Translation Control (TC) register of the deMMUer 
configuration, and you have enabled the deMMUer, then you can 
turn on the deMMUer from within an emulation session, by 
entering the following commands: 

set analysis mode logical 

This turns on the deMMUer, providing logical addresses to the 
analyzer. The analyzer uses these addresses to perform symbol 
searches to satisfy trace specifications and show symbols in trace 
lists. 

set analysis mode physical 

This turns off the deMMUer. Physical addresses will be supplied 
to the analyzer. The trace lists will show the physical addresses, but 
the analyzer will not accept or display source-file symbols. 


The deMMUer default configuration display is shown in figure 5-1. 
You must set up this configuration with valid entries before the 
deMMUer can perform its reverse address translations. Setup 
instructions for the 68030 deMMUer are described in the 68030 
Internal Analyzer User's Guide. 
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deMMUer configuration 


deMMUer hardware disabled 


Translation Control - OOOOOOOOH 

<e sre fcl ps is tia tib tic tid> 


0 0 0 


Virtual Address start - OOOOOOOOH 


Root Descriptor Type -Invalid Descriptor 


Range List - Start E 

A undefined range 

B undefined range 

C undefined range 

D undefined range 

STATUS: Configuring DeMMUer_ 

configure_deMMUer 


range enable disable set 


display return 


Figure 5-1. DeMMUer Configuration Display 
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How To Access 
The DeMMUer 
Configuration 
Display 


Invoke the emulation configuration questions by using the modify 
configuration command. Proceed through the questions until the 
following configuration question can be answered: 


Modify memory configuration? yes 

In the memory mapping display, enter the following command: 

configure_deMMUer 

In the deMMUer configuration display, you can turn the 
deMMUer on or off and define values and ranges to be used by the 
deMMUer during its operation. The procedures you follow to 
make these entries are discussed in the 68030 Internal Analyzer 
User's Guide. 

When you are finished configuring the deMMUer, return to the 
memory mapping display by using the return command. With a 
valid configuration setup, the deMMUer will be able to perform its 
reverse address translations. 
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Target System Interface 


Overview This chapter provides information on: 

■ 68030 pins and how the emulator pod interacts with those 
pins. 

It also provides information on the appropriate use of the 
following emulator and processor features when the emulator is 
used with a target system (in-circuit emulation): 

■ Emulation and target system DSACK and STERM signals 

■ Vector base register 

■ The internal 68030 caches 

■ Using function codes for displaying and modifying 
reserved address space 

■ Enabling/disabling the bus error signal (BERR) 

■ Using DMA 

■ Using the run from ... until command 

■ Using the emulation foreground monitor 

■ Memory access timing issues 

■ Loading absolute files. 


Read this chapter before attempting to connect and operate the 
emulator with your target system. 
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68030 Signals 


CLK 


A(31 -0) 


The following section discusses each of the 68030 pins and how the 
pod interacts with each of those pins. For a summary of the timing 
specifications, and the AC and DC specifications of the 68030 
emulator refer to appendix C. In this section, the emulator/target 
electrical interface is shown for each signal. The interface diagram 
is either with the signal definition or is referenced to a signal that 
has an identical interface. All circuitry referred to is on the active 
probe. 

The clock signal line is unbuffered to the 68030 processor so that 
synchronous timing relationships are maintained. The emulator is 
more of a load on the clock signal than the 68030 processor. For 
the timing specifications given in appendix C to be valid, the clock 
signal must meet the rise and fall time of specifications 4 and 5 in 
appendix C. 


CLK 



The 68030 address bus is not buffered to the target system. The 
emulator loads these signals so that the amount of capacitance they 
can drive is reduced. 


68030 







. _ 




1 |u<50/j,A 

1 ,, <250jxA 
C|N<30pf 






A31 — A0 

FC2-FC0 

R/W 

CBREO 

RMC 

SIZ1, SIZ0 
CIOUT 
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FC2-FC0 


R/W 


CBREQ 


RMC 


SIZ0-SIZ1 


CIOUT 


The Function Code (FC2-FC0) lines are not buffered to the target 
system. The emulator loads these signals so that the amount 
capacitance they can drive is reduced. The emulator/target 
electrical interface is the same as shown for the address bus. 

The Read/Write line is not buffered to the target system. The 
emulator loads this signal so that the amount capacitance it can 
drive is reduced. The emulator/target electrical interface is the 
same as shown for the address bus. 

The Cache Burst Request line is not buffered to the target system. 
The emulator loads this signal so that the amount capacitance it 
can drive is reduced. The emulator/target electrical interface is the 
same as shown for the address bus. 

The Read-Modify-Write Cycle line is not buffered to the target 
system. The emulator loads this signal so that the amount 
capacitance it can drive is reduced. The emulator/target electrical 
interface is the same as shown for the address bus. 

The Size signal lines are not buffered to the target system. The 
emulator loads these signals so that the amount capacitance they 
can drive is reduced. The emulator/target electrical interface is the 
same as shown for the address bus. 


The Cache Inhibit Out signal line is not buffered to the target 
system. The emulator loads this signal so that the amount 
capacitance it can drive is reduced. The emulator/target electrical 
interface is the same as shown for the address bus. 
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AS The 68030 Address Strobe signal line is buffered by the emulator 
prior to going to the target interface. AS is driven to the target 
when the processor is running except when the emulator is in the 
background monitor, or when the bus has been relinquished. The 
AS signal from the target system is also treated as an input during 
DMA so that emulation memory and the analyzer can see those 
cycles. 


+ 5VDC 



Buffering the AS signal causes it to be delayed to the target system. 
This delay may be significant in some systems, but in a system 
which has AS heavily loaded, it may not even be noticable. 


DS, DBEN The 68030 Data Strobe and Data Buffer Enable signal lines are_ 

buff ered by the emulator prior to going to the target interface. DS 
and DBEN are driven to the target when the processor is running 
except when the emulator is in background monitor, or when the 
bus has been relinquished. Buffering these signals causes them to 
be delayed to the target system. 


68030 


FCT244A 


5VDC 


10K 

__ DS, 

DBEN 
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ECS, OCS The 68030 External Cycle Start and Operand Cycle Start signal 
lines are b uffere d b y the e mulator prior to going to the target 
interface. ECS and OCS are driven to the target when the 
processor is running except when the emulator is in background 
monitor (when they are optionally driven), or when the bus has 
been relinquished. Buffering these signals causes them to be 
delayed to the target system.The emulator/target electrical 
interface for these signals is the same as shown for the DS signal. 

D(31 -0) The data bus is buffered between the 68030 and the target 

interface. The buffers only drive the target system during write 
cycles mapped to target memory, or during read cycles in DMA 
that are mapped to emulation memory. The processor receives the 
data from the target system when a read cycle is mapped to target 
memory during normal program operation. Buffering the data bus 
lines causes the emulator to require more setup time than the 
processor. 


D31-D0 


+ 5VDC 



FCT245A 



68030 
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DSACK1 -DSACKO 


BERR 


HALT, AVEC 


The Data Transfer and Size Acknowledge signals are buffered 
between the target system and the 68030. The signal from the 
target system is only sent to the processor during normal cycles 
mapped to target memory, during interlocked emulation memory 
cycles, or during foreground data space cycles. During all 
interlock ed or monitor cycles and during emulation jams, the 
DSACK once asserted, is forced to a 32-bit acces s. Durin g 
interlocked emulation memory cycles, the target DSACK signals 
are not allow ed until th e emulation memory has data valid. 
Buffering the DSACK lines causes the emulator to require more 
setup time than the processor. 


DSACKO 
DSACK 1 
BERR 
HALT 
AVEC 



The Bus Err or signa l is buffered between the target system and the 
68030. The BERR signal can be blocked from going to the 
processor during target cycles and/or emulation memory cycles. It 
is always blocked during monitor and other special emulation 
cycles. 

If the HA LT signa l is asserted at the same time as the BERR 
signal, the BERR signal is not treated as a bus error; but as a retry. 
Retry cycles are never blocked by the emulator. The 
emulator /target electrical interface is the same as shown for the 
DSACK signals. 

The Halt and Autovector signals are not blocked by the emulator. 
The emulator/target el ectrical i nterface for these signals is the 
same as shown for the DSACK signals. 


6-6 Target System Interface 





STERM 


CUN 


CBACK 


The Synchronous Termination signal is buffered between the 
target system and the 68030. The signal from the target system is 
only sent to the processor during normal cycles mapped to target 
memory, during interlocked emulation memory cycles, or during 
interlocked foreground data space c ycles. Dur ing interlocked 
emulation memory cycles, the target STERM signal is not allowed 
until the emulation memory has data valid. Buffering the STERM 
signal line causes the emulator to require more setup time than the 
processor. 


+ 3.25VDC + 3.25VDC 



The Cache Inhibit In signal is buffered between the target system 
and the processor. It is not blocked by the emulator. The 
emulator/targ et electric al interface for these signals is the same as 
shown for the STERM signal. 

The Cache Burst Acknowledge signal is buffered between the 
target system and the processor. The signal is blocked except 
during normal target cycles mapped to allow bursting. The 
emulator /target electrical interface is the same as shown for the 
STERM signal. 
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BG The Bus Grant signal is buffered between the processor and the 
target system. The signal is blocked when DMA is disabled. 



BG_ 

IPEND 

STATUS 

REFILL 


IPEND The Interrupt Pending signal is buffered between the processor and 
the target system. The signal is blocked during interrupts caused 
by the emulator break facility. Whether or not the signal is 
blocked can be configured. Refer to chapter 4 for configuration 
information. 


STATUS, REFILL The Microsequencer Status and Pipe Refill signals are not blocked 

by the emulator. The emulator/target electrical interface for these 
signals is the same as shown for the BG signal. 


BR, BGACK The Bus Request and Bus Grant Acknowledge signals are buffered 
between the target system and the processor. These signals are 
blocked when DMA is disabled. 



BR 

BGAC K_ 

IPL2- IPL0 

CPIS 

MMUDIS 


IPL2-IPL0 The Interrupt Priority Level signals are buffered between the target 
system and the processor. These signals are blocked while the 
emulator is in the background monitor. Use of the emulator 
foreground monitor can delay handling of an interrupt, his is 
because the emulation monitor is an interrupt handler itself and 
maskable interrupts are normally disabled during execution of the 
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c 

CDIS, MMUDIS 


RESET 

e 


vcc 

c 


monitor. Maskable interrupts can be enabled during execution of 
some parts of the emulation monitor by customizing the emulation 
monitor code for the specific application. For further information 
on the emulation monitor and how to customize the code refer to 
chapter 7. The emulator/tar get e lectrical interface for these signals 
is the same as shown for the BR signal. 

The Cache Disable and MMU Disable signals can be blocked by 
the emulator. Whether or not these signals are blocked is 
determined by how you configure the emulator (refer to chapter 4 
for more information on emulation configuration). The 
emulator/target electrical interface for these signals is the same as 
shown for the BR signal. 

The Reset signal is not buffered by the emulator, although the 
emulator can drive this signal because it is an open collector signal. 


+ 5VDC 


RESET 



The emulator monitors the target system VCC to determine when 
the emulation pod is connected to an active system. The target 
system interface is disabled until VCC is detected. The current 
draw from the target VCC is a few milliamps. 
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Emulation And 
Target System 
DSACK and 
STERM Signals 

Interlocking 
Emulat ion Memory 
DSACK and STERM 
an d Target DSACK 
and STERM Signals 

Note 


If your target system memory req uires wai t sta tes, you s hould 
interlock the em ulation m emo ry DSAC K and STERM signals with 
the target system DSACK and STERM signals. This causes 
accesses to emulation memory and accesses to target memory to 
properly reflect system performance when the emulator is removed. 


When operating the emulator at 25 MHz, four wait states will be 
added EVEN if the target system responded with a zero-wait-state 
termination during interlock operation. At 33 MHz, the emulator 
adds six wait states to emulation memory accesses. 


If target system memory requires wait states, the first target 
memory access after a n emulat ion memory a ccess may fail if 
emulation and target DSACK and STERM signals are not 
interlocked. See the timing diagram in figure 6-1. 

The following rules should be used to de ter mine whe ther or not to 
interlock emulation and target DSACK and STERM signals. 

1. If the target system generates DSACK and STERM signals 
for all emulatio n m emory ad dress ranges, emulation and 
target DSACK and STERM signals should be interlocked. 


2. If the tar get system does not generate DSACK and 
STERM signals for a range of emu lation me mory, 
emulation and target DSACK and STERM signals must 
not be interlocked. 
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Target 

- 4 

DSACK -1 


Emulation 

Memory 

- 2 

DSACK -1 


1. An access to emul ation memory. 

2. Emulation memory DSACKs terminate cycle 
properly. 

3. Access to tar get memory. 

4. Target DSACKs from emulation memory accesses 
(1) prematurely terminate the cycle before 

correct data is available from target memory. 


Figure 6-1. Memory Access Timing, No DSACK Interlock 


3. If there is n o target sy ste m (that is; out-of-circuit 
emulation), DSACK and STERM signals cannot be 
interlocked. 

Each block of emulation memory can be individually interlocked 
during emulation configuration. 


DSACK and STERM Many target systems violate 68030 DSACK and STERM signal 
Signal Problems In specifications. These violations are usually marginally acceptable 
Taraet Svstems to the 6 ^30 CPU in the target system, but cause problems when 
y y the emulator is plugged in. These specification violations usually 

result in improper data fetches from memory and cause target 
system failure with the emulator installed. 


Use Of Open Collector Drivers 

One of the most common pro blems is asso ciated wit h the use of 
ope n-collecto r drivers on the DSACK and STERM lines. DSACK 
and STERM lines often have pullup resistors that pull the DSACK 
and STERM signals high at the termination of a memory cycle. 
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Imprope r values for pullup resistors can cause DSACK and 
STERM signals not to be pulled up fast enough and may interfere 
with the next cycle. This occ urs when the pullup resistor value is 
too large to return DSACK and STERM to a proper high leve l 
before th e next cycle begins. In this case, the still low DSACK and 
STERM signal causes a premature termination of the second cycle, 
resulting in improper data fetches by the CPU. 

Early Removal Of DSACK Signals 

Some target system designs do not adhere t o the 68030 
specification which states that the DSACK signals must not be 
removed prior to the negation (low to high transition) of the 
address strobe at the end of a cycle. In the simplest case, this results 
in "no DSACK" messages appearing in the tracelist, which in turn 
causes inverse assembly failure. More seriously, the emulator may 
completely malfunction depending on how early the DSACK signal 
is removed prior to address strobe transition. 

Isolating The DSACK Problem 

If you suspect that your target system may have either of the 
preceding problems, use a timing analyzer to help isolate the 
problem. Take a trace of the CPU clock, address strobe, data 
strobe, and the DSACK signals during the failing cycle (use the 
BNC’s on the back of the HP 64120 cardcage to drive the trigger, if 
possible). Examine the results and compare your findings to the 
electrical specifications of the 68030 processor and the HP 64430 
emulator. 
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Using The Vector 
Base Register 


The 68030 CPU gets exception vectors from the exception vector 
table located at the address contained in the Vector Base Register 
(VBR). 

The 68030 emulator uses a jamming technique for breaks and 
software breakpoints. Therefore, the value of the VBR is not 
needed to perform most monitor functions. This implies that the 
vector table may be located anywhere without adversely affecting 
emulator operation. 

The single-step feature, when using the foreground monitor, does 
require the use of the trace exception vector (VBR 4- 24H). If the 
single-step feature is to be used, you must make sure that the trace 
exception vector always points to the monitor 
(MONITOR_ENTRY). 

The monitor can handle various exceptions by displaying a status 
message, entering a loop within the monitor, and then waiting for 
user intervention. These exceptions include Bus Error, Address 
Error, Divide by zero, etc. If you use these exceptions, you must 
maintain the exception vector table so that the vectors in use 
always point to the appropriate monitor location. 
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Using The Internal 
68030 Caches 


Using the internal 68030 caches affects several functions of the 
68030 emulator. The following sections discuss use of the internal 
caches and their effect on emulator operation. 


Cache Control When the emulator is operating out-of-circuit, the "Enable 

Caches?" configuration question has a different interpretation than 
when plugged into a target system. When using the emulator 
out-of-circuit, a "ye s" answ er to the "Enable Caches?" configuration 
question forces the CDIS signal high within the pod. When using 
the em ulator in-circuit, a "yes" answ er con nects the target system 
CDIS signal to the emulator C PU’s C DIS input, allowing the 
emula tor to track target system CDIS. In both cases, a "no” answer 
forces CDIS low within the emulator. 


Recall also that the target system CDIS must be high, and bit zero 
of the Cache Control Register (CACR) must be set to 1 for the 
instruction cache to be enabled and bit 8 of the CACR must be set 
to 1 for the data cache to be enabled. 

If the target system uses the internal 68030 caches, the caches must 
be enabled by answering "yes" to the "Enable Internal Caches?" 
configuration question. 

When the CDIS signal from the target system is set to 1, the caches 
still are not enabled until bits 0 and 8 of the (CACR) are set to 1, 
as shown in the following example: 

MOVEQ.L S#11,D0 

MOVEC DO,CACR software enable cache 

Enabling the caches affects analysis trigger, store, count, and 
Global Context functions. Additionally, some program read states 
may be missing from the trace list. 

The caches are not frozen on entry to the foreground monitor. This 
results in overwriting the cache contents. 

If a breakpoint is set for an address currently contained in cache, 
the breakpoint will not be recognized until the CPU fetches from 
that address in main memory again. The run until command is 
similarly affected since breakpoints are used in the command 
implementation. 
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Analysis With Cache The 32-bit internal analyzer can capture any cycle that occurs 

external to the 68030 CPU. When caches are enabled, read cycles 
may occur only internal to the CPU. This is the general case with 
tight program loops and with high performance code segments that 
are frequently locked in cache. Since the analyzer cannot capture 
internal cycles, it has no way to display these cycles in the tracelist. 
This can result in missing trace data and high-level source lines, 
and even improper disassembly. The analyzer will also miss the 
occurrence of trigger, store, count, sequence or context patterns if 
they occur only as internal cycles. 

In general, any program segment that executes from cache will 
generate some external cycles, the major exception being timing 
loops. In these cases, you may be able to select trigger and store 
patterns that correspond to external cycles. If no external cycles are 
normally generated, you may be able to place "markers" in the 
cached code such that the code will generate an external cycle for 
analysis purposes when executed. 

The mapping function allows pages of target memory to have 
caching disabled for analysis purposes 

Since the analyzer contains a high precision cycle-to-cycle timer, 
you can usually examine the tracelist to determine where cache 
execution occurred. 


Using Breakpoints You may see situations where breakpoints do not appear to be 
With Caches Enabled functioning properly when the instruction cache is enabled. This 

can happen when you are using the "run until" command as well as 
breakpoint commands. 

Consider the following segment of code (a simple software timing 
loop), and assume that the cache is enabled: 


Address 

Code 




1000: RELOOP 

NOP 




1002: 

NOP 




1004 : 

NOP 




1006: 

NOP 




1008: 

NOP 




100A: 

SUBQ.L 

#1,D0 

; decrement 

loop counter 

100C: 

BNE 

RELOOP 

; reloop if 

not 0 
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Because the instruction cache is enabled, no external memory 
cycles are generated for addresses 1000H thru 100CH after their 
initial load into cache. Breakpoints set at any cache resident 
address may never be encountered. This situation occurs when the 
CPU does not generate an external program read cycle to memory 
and therefore never "sees" the breakpoint that was set. 

Target Memory Breakpoints 

Breakpoints set in target system memory differ from those set in 
emulation memory. If the breakpoint address is mapped to target 
system memory, the monitor must intervene in order to set the 
breakpoint. Execution of the monitor overwrites cache locations 
previously occupied by the user program. When the emulation 
monitor is exited, the user program is fetched again from memory, 
breakpoint included. This results in normal breakpoint behavior. 

Emulation Memory Breakpoints 

This problem is worse when the breakpoint address is mapped to 
emulation memory. Due to the dual-port nature of the memory 
system, the host sets breakpoints in emulation memory without 
requiring execution of the emulation monitor. In this case, the 
mechanism of setting breakpoints does not clear cache and force a 
refetch of the newly specified breakpoint. 

For breakpoints to function properly out of emulation memory, 
you need to clear the cache before setting or resetting the 
breakpoint. Do the following steps before setting a breakpoint: 

1. Break to the emulation monitor program. 

2. Display CPU registers. 

3. Modify CACR bit C to 1 and then to 0. 

4. Set the breakpoint or enter the run until command. 

5. Exit the monitor by executing a run command. 
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When the breakpoint is hit, you can remove it from cache by 
adding 68030 instructions to the emulation monitor that will set 
and clear the CACR C bit. 


The preceding comments apply to setting software breakpoints as 
well as disabling software breakpoints. 


Using Function 
Codes For 
Displaying And 
Modifying 
Reserved Address 
Space 


When the use of function codes is enabled during a memory 
mapping session, the display and modify commands use the 
function codes specified in the command. When function codes are 
disabled, function code 0 is used for all memory reference 
commands. 


Some target systems do not use function codes to differentiate 
between user and supervisor space or program and data space, but 
do decode the "reserved" address spaces (function codes 0,3 and 4) 
to generate interrupts or inhibit DSACK generators. In these 
cases, the emulation monitor may be customized to allow the use 
of a non-zero function code for the display, modify, load, and store 
emulator commands. 

This modification requires changing two assembly statements in 
the monitor "COPY" routine as shown in the following listing: 
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command 2 . access user memory 




COPY 

* copy parameters from CPU space (SFC and DFC were setup by MONITOR_LOOP) 


* copy byte count from parameter slot 1 
MOVES.L PARM1,DO 


* copy source address from parameter slot 2 
MOVES.L PARM2,AO 


»> * copy source function code from parameter slot 3 
»> * MOVES. L PARM3 , D1 


»> * force user data function code 
»> MOVES.L #2 1 D1 


* copy destination address from parameter slot 4 
MOVES.L PARM4 f A1 


»> * copy destination function code from parameter slot 5 
»> * MOVES.L PARM5 , D2 

»> * force supr data function code 
»> MOVES. L *5,D2 


* copy access mode from parameter slot 6 
MOVES.L PARM6,D3 

Modifications to the emulation monitor code for non-zero 
function code access to target system memory include adding the 
two new source lines shown in lower-case and commenting out 2 
lines as shown in the listing. The added and modified lines are 
indicated by arrows (>>>). 
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Enabli ng/Disabling The 68030 emulator allows the bus error (BERR) signal to be 
B ERR received or not received during accesses to emulation memory. 

c 

If the target system generates bu s errors for emulation memory 
address ranges, the rece ption of B E RR shoul d be disabled. This 
would normally occur if DSACK or STERM signals are not 
generated for emulation memory accesses. 

If the target system generates DSACK or STERM signals for 
emulat ion memory accesses, then it probabl y does not generate 
BERR for these cycles. In this case, BERR actually indicates a 
failure, and should be enabled in the emulator. 


If any devices share the 68030 bus and are able to perform DMA, 
then DMA should normally be enabled. This enables the CP U to 
receive the Bus Request (BR) signal, generate a Bus Grant (BG) 
r esponse s ignal, and receive the Bus Grant Acknowledge 
(BGACK) response from the bus requester. The handshake 
sequence for DMA transfers is shown in figure 6-2. 



Figure 6-2. DMA Bus Request/Bus Grant Timing 


Using DMA 

C 
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If DMA is disabled, the CPU will not receive the bus request 
signal, and will not allow DMA cycles. This would be desirable in 
order to characterize system performance in a situation where 
DMA could not occur. 

The user who has enabled DMA has a secondary option of 
enabling or disabling DMA to/from emulation memory. 

If DMA to emulation memory is enabled, the DMA hardware has 
access to read from or write to emul ation mem o ry. If DSA CK or 
STERM signals are interlocked, the DSACK or STERM signals 
for these accesses are supplied by the target system. The DMA 
master must generate cycles that conform to 68030 timing 
requirements. 

If DSAC K or STERM signals are NOT interlocked, then no 
DSACK or STERM signals are returned t o the targ et system. T his 
would cause the DMA hardware to hang if DSACK or STERM 
signals are required for cycle termination. 

If the option to DMA to/from emulation memory has been 
DISABLED, the DMA cycle will still be allowed to occur, but no 
information will be written to, or read from emulation memory. 
See the timing diagram in figure 6-3. 
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1. DMA device requests the bus. 

2. The 68030 indicates that bus will be relinquished. 

3. DMA device indicates that the bus is in use. 

4. DMA device generates a write with a target memory address. This cycle 
occurs normally. 

5. DMA device generates a read with an emulation memory address. This cycle 
does not return valid data since DMA to emulation memory is disabled. 

6. DMA device generates a write with an emulation memory address. This cycle 
does not modify emulation memory since DMA to emulation memory is disabled. 

7. DMA device generates a read with a target memory address. This cycle occurs 
normally. 

8. DMA transaction is complete. 


Figure 6-3. DMA Timing Diagram, DMA Disabled 


Target System Interface 6-21 




Using The Run 
From... Until 
Command 


The run command must be used properly to avoid serious, stack 
related problems in the software being executed. 


One of the main causes of target system "failure" while using the 
run command is the stack not being setup and/or restored properly 
by the software being executed. One common situation is for 
parameters to be placed on the stack prior to calling a procedure. 
(Parameter stacking code including the actual procedure call is 
usually referred to as the "calling sequence.”) Assume for example 
that a procedure, PROC1 expects the stack frame shown in figure 
6-4. 
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Often, PROC1 will access the stacked parameters by referencing 
parameter requests to the stack pointer. This means that parameter 
"A" can be found at address A7+12, parameter "B" at address 
A7+8, etc. 

If the parameters are not stacked, and/or the return address is not 
present, then the usual parameter references A7 + 12, A74-8, etc. 
may reference uninitialized stack areas. Also, the return address 
used by PROC1 will be incorrect. This will usually result in a 
software failure both within PROC1 (because the parameter values 
are wrong) and on exit from PROC1 (because the return address 
was not set properly). Depending on emulator memory mapping, 
the "stack" areas referenced by A7+12, etc. may actually fall within 
guarded memory area, resulting in a guarded memory access 
message. 

Executing the command "run from PROC1" prior to stacking the 
parameters and setting the return address is one case where this 
could happen. Problems also occur if a "run from < address >" 
command is executed and CPU registers, or memory locations are 
not properly initialized for the code to be executed at <address >. 

Using the command "run until" can also cause problems. This case 
is different from the "run from" case in that software problems may 
occur on a subsequent "run" command after the "until" condition is 
satisfied. If a "run" command is executed after executing the "until" 
breakpoint, no problems should result, because the CPU will 
continue executing the user program from the point where it left 
off. If a "run from" command is executed after the "until" 
breakpoint, the stack, CPU registers and memory locations may be 
improperly set for the code to be executed at the "run from" 
address. 

These situations cannot be corrected within the feature set of the 
emulator. You must be aware of your software requirements, and 
the mechanism used to implement the run commands. A detailed 
explanation of how the run command works is given in chapter 10. 
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Using The Emul¬ 
ation Foreground 
Monitor 


Loading the Monitor 


Resetting Into The 
Monitor 


The following rules must be followed when loading the emulation 
monitor: 

1. Both program and data spaces of the monitor must be 
mapped to RAM as opposed to ROM. The monitor 
transfer buffer, as well as many monitor ’’housekeeping” 
variables must be read and write accessible, and must 
therefore be mapped to RAM. 

In addition, portions of the monitor must write to other 
monitor program locations. Since writes to ROM are 
always blocked, the program section, as well as the data 
section, of the monitor must be mapped to RAM. 

2. The emulation monitor is executed in response to a level 7 
interrupt. Therefore, it is always executed within 
supervisor space and must be located in supervisor space. 
If the supervisor/user function code bit is not in use, this 
restriction does not apply. 

The emulation software recognizes only program symbols. In the 
case of the monitor, the symbol addresses are assumed to be 
associated with the SUPR_PROG function code (since the 
monitor is basically an interrupt routine). Thus, when the host 
writes control information to, or reads information from the 
monitor, it must use the SUPR_PROG function code. 


The "reset into monitor" facility of the emulator makes use of 
internal jamming circuitry to supply both an initial stack pointer 
and an initial program counter to the CPU. These values 
correspond to the values of monitor symbols SP_TEMP and 
RESET_ENTRY respectively.If the background monitor is being 
used, the initial stack pointer must be defined since stacking is 
done in foreground monitor. 
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Jamming from reset occurs only if the emulator caused the reset via 
the "reset" softkey. If the target system asserts the CPU reset signal, 
the jamming circuitry is disabled and startup from reset occurs 
normally, with stack pointer and program counter values being 
supplied from memory system addresses 0-7. 

The setting of the initial stack pointer value is critical to proper 
system operation. Since SP_TEMP is only provided as a small 
temporary stack for use with the monitor, the stack may be easily 
overflowed once a "run from ..." command is given, and the target 
system program begins execution. Portions of the monitor may be 
overwritten if the SPJTEMP stack overflows. 

To ensure proper operation, be sure to either extend the 
SP_TEMP stack to meet target system requirements, or modify the 
SP_TEMP value to point to the usual target system stack. This can 
be done by including an appropriate "equate" statement in the 
monitor, while commenting out the normal SP_TEMP label in the 
monitor. For example: 

SP_TEMP EQU < target system stack address > 

Another approach is to be certain that software execution as a 
result of the "run from ..." command properly initializes the stack 
pointers to values appropriate to the target system. 

When the emulator is in a reset condition, one of two messages 
appears on the emulator status line above the softkeys. If the word 
"Reset" appears, the present reset condition occurred as a result of 
the emulator. The presence of a lower case "reset" indicates that 
the target system is presently asserting the CPU reset signal. The 
68030 emulator can be instructed to enter the emulation monitor 
when a "run" command is issued after "Reset" (jamming only occurs 
if the reset signal is asserted by the emulator). This causes the 
initial program counter and initial stack pointer vector to be 
ignored. Instead, the jamming circuitry supplies these values based 
on the current location of the monitor. 

A possible difficulty exists if the target system performs some 
hardware and/or software initializations on reset. If "reset into 
monitor" is used, these initializations are not performed before 
monitor execution is begun. 
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Memory Access 
Timing Issues 


33 MHz 68030 
Microprocessor 


HP 64430 68030 
Emulation System 


Access time is the time interval during a 68030 microprocessor 
read cycle beginning when the 68030 microprocessor places an 
address on the address bus and ending when valid data is present 
on the microprocessor’s data pins. 

Appendix C contains tables listing timing comparisons between the 
MC68030 processor and the HP 64430 emulator. 

For a 33 MHz 68030 microprocessor running at maximum speed in 
synchronous mode with no wait states: 


Access Time = Cycle Time + Clock Pulse Width - Specification 6 - 
Specification 27 

Spec. 6 = Clock High to FC,Size,RMC,CIOUT,Address Valid 
= 14 ns (max), 

Spec. 27 = Data-in Valid to Clock Low (Synchronous Setup) 
= 1 ns (min), 

Cycle Time = 30 ns (min), 

Clock Pulse Width = 14 ns (min). 

Therefore: 

Access Time (max) = 30 ns 4-14ns -14 ns -1 ns = 29 ns 

For the HP 64430 68030 emulation system, the emulator adds the 
following delay: 

Data lines buffered with a 74FCTA245 = 5 ns (max) 

An easy way to calculate the maximum access time allowed by the 
emulator is to use the timing comparison tables provided in 
appendix C of this manual. The relevant worst case specifications 
for the emulator are as follows: 

♦Access Time (max) = Cycle Time + Clock Pulse Width - 
Specification 6 - Specification 27 

♦Specification 27 includes value added because of data line 
buffering shown above. 
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Spec. 6 = 14 ns (max) 

Spec. 27 = 6 ns (min) 

Cycle Time = 30 ns (min) 

Clock Pulse Width = 14 ns (min) 

Therefore: 

Access Time (max) = 30 ns +14 ns -14 ns -6 ns = 24 ns 


Loading An 
Absolute File 


When an absolute file is generated, it frequently is composed of 
various "sections” containing code or data: 




oooohN 

CODE 

OFFFH 


1000H 

DATA 

2FFFH 


3000H 

CODE 

3FFFH / 


> 


Absolute File Test.X 


A memory map resembling that shown below might normally be 
generated: 



Addr. Range 

0000H - OFFFH 
1000H - 2FFFH 
3000H - 3FFFH 


Attribute 

EMUL RAM 
EMUL RAM 
EMUL RAM 


Function Code 

SUPRPROG 
SUPR_DATA 
USER PROG 


default = guarded 
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Note that upon execution of the following command, a guarded 
access will occur: 

load memory Test.Xfcode SUPRPROG Return 

This is due to the fact that the Toad" mechanism attempts to load 
the entire file using the SUPR_PROG function code. In the case of 
Test.X (with the memory map above), address range 0000H - 
OFFFH is mapped to emulation memory when the function code is 
SUPR PROG. The remaining address ranges of Test.X are 
actually mapped to GUARDED memory when the function code is 
SUPR_PROG. This is because the default is set to GUARDED, 
and because there are no mapping definitions for SUPR_PROG 
covering the remaining address ranges of Test.X. 

Similar symptoms would be observed with either of the following 
commands: 

load memory Test.Xfcode SUPR_DATA 
load memory Test.X fcode USER_PROG 

The Toad memory..command is defined as a vehicle to "load all 
memory areas’' present in a given absolute file. (Guarded, as well as 
target and emulation memory.) 

The Toad memory emulation..." command is used to Toad only 
areas mapped to emulation memory” in a particular absolute file. 

Thus, to properly load Test.X, the following three commands 
would be issued: 

load memory emulation Test.Xfcode SUPR_PROG 
load memory emulation Test.Xfcode SUPR_DATA 
load memory emulation Test.Xfcode USERJPROG 

The "load memory target...” command is provided to "load only 
areas mapped to target memory” in a given absolute file. 
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Debugging Plug-in 
Problems 


Review the 
Configuration 


When the emulation pod is connected to a target system, the 
emulator operation becomes more complex. More hardware has 
been added to the entire system and the user must be 
knowledgeable about the target system resources. The following 
information should be used as a guide to isolate problems that are 
encountered when connecting the emulation pod to a target system. 

If the target system has tight timing specifications, the emulator 
may cause some signals to violate either the emulator 68030 or the 
target system timing requirements. 

An incorrect configuration file can result in improper operation. 
Review the entire configuration file to make sure that all of the 
questions are answered correctly for your target system. If you are 
not sure how to answer a particular question refer to chapter 4 and 
sections of this chapter for details concerning configuration and 
information about the target system interface. The command 
"!more <configfilename> .EA" can be used to view the entire 
configuration file. 

Target systems that are able to operate without the emulation pod 
should be able to start with the default configuration file. This file 
is used whenever a new emulation session is started. The default 
configuration enables all of the target system signals, maps all 
memory as target RAM and specifies that the emulation monitor is 
not loaded. Verification of proper operation should be made using 
the internal analyzer and indications from the target system. 

Plug-in failures with the default configuration should be isolated 
before attempting to use configurations that use emulation 
memory or the emulation monitor. Once the default configuration 
works properly add emulation memory and an emulation monitor. 
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Use the Internal 
Analyzer 


Use the Status 
Messages 


The internal analyzer can be used with any configuration without 
interfering with the emulation of the processor. It passively 
monitors each bus cycle that the processor executes. All of the 
analyzer data can be displayed without disrupting the emulation 
process. The analyzer can be used to verify the proper operation of 
the program being executed and the proper operation of the 
hardware. 

Debugging plug-in failures with the internal analyzer should start 
with a Trace TRIGGER_ON a= Oh” specification before allowing 
the processor to run. This will capture all bus cycles starting with 
the reset address. Particular attention should be given to the bus 
size bit (B)and the data field of the first few cycles. The triggering 
capability of the analyzer can be used to capture conditions that are 
the result of a failed interface by using the "trace TR1GGERJ3N 
<failure_condition>" specification. These conditions are usually 
incorrect code branches or status conditions such as halt or 
shutdown. 

Failures that occur only during certain types of operations such as 
a CPU space address or a particular place in memory can be 
debugged using the capability of the analyzer to drive one of the 
rear panel BNC outputs or the Intermodule Bus (IMB). The 
trigger condition should be set up for the bus cycle in error and the 
trigger should be enabled to drive the BNC or IMB. These outputs 
can then be used with measurement tools such as timing analyzers 
or oscilloscopes that can be used to monitor the target system. 
When observing the data, keep in mind that the trigger pulse 
actually occurs between one and two CLK cycles after the end of 
the bus cycle. 

Appendix C contains a complete list of emulation status line 
messages and their causes. Many of these conditions are not 
displayed unless no bus cycles have occurred for more than 250 
milliseconds. If your system creates conditions that result in the 
68030 not generating a bus cycle for more than 250 milliseconds, 
then the status message related to that condition can be ignored. 
Status messages such as "Write to ROM fc= <code>", "halted" and 
"slow device fc= <code>" provide address or status information 
that can be used by the analyzer as a trigger specification to trace 
the error condition. 
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Run Performance Refer to the HP 64430 HP-UX Hosted 68030 Emulator Service 
Verification (PV) Manual for instructions for running performance verification on 

the emulation system. 


If All Else Fails ... If the emulator is configured properly, and the target program and 

foreground monitor are loaded, unexplained behavior may still 
exist. This is frequently due to foreground monitor interaction 
with the target software and/or hardware. 

In the software category, check that it is appropriate to disable 
interrupts while in the foreground monitor. Some systems with 
delta-time-interrupt structures for real-time clocks, operating 
system functions, etc., will crash if the delta-time-interrupt is not 
serviced within a preset time limit. The foreground monitor can be 
customized to enable or disable interrupts as required. See the 
"Continuing Target System Interrupts While In The Emulation 
Monitor" section of chapter 7. 

It is possible to "disable" the normal target system function of the 
-V 3 , level 7 (NMI) interrupt through vector table modifications, and a 
small amount of additional foreground monitor code. 

Ensure that the program being executed is not accidentally 
^ overwriting the foreground monitor or vice versa. 

Use of the analyzer to examine software behavior is an effective 
means to solve emulation problems. 

Obtain a listing of the foreground monitor and the program being 
executed, and use the analyzer to verify proper operation of both. 

Set the analyzer to trigger on the foreground monitor entry point 
(MONITOR_ENTRY), with the trigger position set to the center 
of the trace. This will allow you to examine CPU activity 
surrounding the foreground monitor entry. Your can observe the 
stacking activity of the level 7 interrupt, as well as emulator 
generated jam cycles. This will enable you to determine if the 
foreground monitor is being initiated properly. 
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Ensure that the foreground monitor exits and returns to the 
normal program properly. Set the analyzer to trigger on the 
foreground monitor exit point (EXIT_MON), and observe the 
unstacking as a result of the RTE instruction. Be sure that the 
stack contents have not been corrupted, and that the program 
returns to the expected location. 

Remember that the use of any foreground monitor function will 
affect the timing of executing programs, and may be the cause of 
hardware and software anomalies. 
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7 



The Emulation Monitor Programs 


Overview 



This chapter: 

■ Provides a comparison of the emulation foreground and 
background monitor programs. 

■ Discusses the need for, and when to use, the emulation 
foreground and background monitor programs. 

■ Discusses the break function as related to the emulation 
monitor programs. 

■ Describes the emulation foreground monitor program. 

■ Provides information for customizing the emulation 
foreground monitor. 

■ Describes the emulation foregrond monitor memory 
requirements. 

■ Describes the emulation foreground monitor linking 
requirements. 

■ Describes the rules for loading the emulation foreground 
monitor. 



See chapter 6, Target System Interface, and chapter 10, How the 
Emulator Works, for additional information about the emulation 
monitor and its interactions with the host computer and your 
target system. 
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Introduction 


The emulation monitor program is the means by which many of the 
emulator functions are implemented. Functions implemented with 
the emulation monitor are: 

a Read/write target memory. 

B Display/modify 68030 registers. 

■ Display/modify coprocessor registers. 

■ Execute user program. 

u Break from user program by: 

- analyzer generated break 

- keyboard break 

- software breakpoint 

- jump from user program 

- memory access violation break. 

B Reset into monitor. 

H Single step by opcode. 

■ Coordinated emulation start. 


A standard emulation foreground monitor source file is supplied 
with each emulation system. This file must be assembled and linked 
by the user before using. Typically, the emulation monitor is 
assembled and then linked with the user program to form one 
software module. This module is then loaded into memory. The 
loaded foreground monitor program enables emulation system 
functions to operate properly. 

You can modify the emulation foreground monitor to 
accommodate a particular target system or to expand the 
emulation monitor’s capabilities. Comment delimiters must be 
removed from some functions in the monitor before they can 
function. If you modify the emulation foreground monitor, the 
basic communication protocol between the emulation foreground 
monitor and the emulation software must be maintained. A 
detailed description of the communication protocol and the 
standard emulation monitor is given in this chapter. 
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Comparison of 
Foreground and 
Background 
Monitors 

Background Monitors 


Foreground Monitors 


An emulation monitor is required to service certain requests for 
information about the target system and the emulation processor. 
For example, when you request a register display, the emulation 
processor is forced into the monitor. The monitor code has the 
processor dump its registers into certain memory locations, which 
can then be read by the emulator system controller without further 
interference. 


A background monitor is an emulation monitor which overlays the 
processor’s memory space with a separate memory region. Entry 
into the monitor is accomplished by jamming the monitor 
addresses onto the processor’s data bus. 

Usually, a background monitor will be easier to work with in 
starting a new design. The monitor is immediately available upon 
powerup, and you don’t have to worry about linking in the monitor 
code or allocating space for the monitor to use the emulator. No 
assumptions are made about the target system environment; 
therefore, you can test and debug hardware before any target 
system code has been written. All of the processor’s address space 
is available for target system use, since the monitor memory is 
overlaid on processor memory, rather than subtracted from 
processor memory. 

However, all background monitors sacrifice some level of support 
for the target system. For example, when the emulation processor 
enters the monitor to display registers, it will not respond to target 
system interrupt requests. This may pose serious problems for 
complex applications that rely on the microprocessor for real-time, 
non-intrusive support. Also, the background monitor code can’t be 
modified to handle special conditions. 

A pregtmind monitor may be required for more complex 
debugging and integration applications. A foreground monitor is a 
block of code that runs in the same memory space as your program. 
Foreground monitors allow the emulator to service real-time 
events, such as interrupts or watchdog timers, while executing in 
the monitor. For most multitasking, interrupt intensive 
applications, you will need to use a foreground monitor. 
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You can tailor the foreground monitor to meet your needs, such as 
servicing target system interrupts. However, the foreground 
monitor does use part of the processor’s address space, which may 
cause problems in some target systems. You must also properly 
configure the emulator to use a foreground monitor (refer to 
chapter 4 "Answering Emulation Configuration Questions"). 

You may link the foreground monitor with your code. However, if 
possible, linking the monitor separately is preferred. This allows 
the monitor to be downloaded before the rest of your program. 
Linking monitor programs separately is more work initially, but it 
should prove worthwhile overall, since the monitor can then be 
loaded efficiently during the configuration process at the beginning 
of a session. 


Using Both 
Foreground and 
Background 
Monitors in the 
HP 64430 
Emulator 


Most conventional emulators are implemented with either a 
background or foreground monitor as the emulation control 
program. The emulator designer makes the appropriate 
compromises regarding the emulator’s transparency during 
running the emulation monitor and picks one type of monitor or 
another in implementing the emulator. 


Due to the on-chip MMU of the 68030 processor, however, and 
due to the full virtual system support provided by the HP 64430 
emulator, both background and foreground monitors are provided 
and supported in the product. The decision by the user to enable 
either monitor is governed by the development stage and nature of 
the target system. 

When to Use the It is recommended that background operation be chosen during 
Background Monitor the early Stage of hardware development where full functionality of 

the target’s interrupt, bus error, and other asynchronous events is 
not needed yet. The background monitor in that case has the 
advantage of being easy to use and can enable the emulator to be a 
stimulus for aiding in turning on the target hardware without 
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When to Use the 
Foreground Monitor 


requiring the target system to be fully functional. For example, the 
display/modify target memory feature can be used to stimulate the 
target’s memory interface and help the designer in troubleshooting 
any defects in that part of his circuitry. All the emulator would 
show while in background is the bus cycle referencing the target 
address. With the aid of an external timing analyzer (for example 
the HP 16500A), the user can monitor the target’s signal behavior 
during that cycle and find any problem(s) the target might be 
having. 

Another feature that is provided by the background monitor and 
not supported in foreground is the display/modify physical 
memory. The implementation of this function requires that the 
on_chip MMU be temporarily turned off so that logical and 
physical addresses are identical. This is not possible during 
foreground operation since the foreground monitor is running as 
part of the virtual system. 

If the target system hardware is close to being completely 
functional, then foreground monitor operation is more desirable. 
The emulator runs in a more transparent mode than with 
background. Interrupts, bus errors, and all other exceptions can be 
handled by the target system software as if the emulator were not 
present. All emulation and analysis functions are available to the 
user. The monitor program customization allows the user to add, 
delete, or change the source code to fit the particular application. 
Messages relating to certain events can be added and diplayed on 
the emulation terminal, and the target programs can jump to the 
monitor at any time. Display/modify of coprocessor registers can be 
acheived by adding the proper code to the monitor program. 

In systems using the on-chip MMU of the 68030 processor, 
external memory in the target system and emulation memory are 
accessed as physical addresses. Since the emulation host 
communicates with the emulation monitor through the logical 
space, and due to the paging and swapping nature of the 68030 
MMU, the requirement that the foreground monitor be mapped to 
emulation memory was waived. Hardware was added to the 
emulator to allow for the foreground monitor to be linked in the 
logical space with the rest of the target code where the eventual 
physical location is defined at run time. The special data area of the 
monitor, where the host communication happens, is located in a 
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Customization of the 
Monitor Programs 


The Break 
Function And The 
Emulation Monitor 


special memory mapped to the untranslated CPU space of the 
processor. This makes it much easier for the foreground monitor to 
be installed and used. 

The background monitor can not be customized by the user. 


The source code for the foreground monitor is provided with the 
HP64430 product and can be modified to best fit the target 
application. Customizing the emulation foreground monitor is 
discussed in another section later in this chapter. 


The emulation break circuitry uses the NMI (INT7) resource of the 
processor to force the user program to be interrupted and the 
emulation monitor to be entered. A break can be generated for an 
illegal memory reference, a bus condition that the analysis card 
detects, a request by the emulation software, or from the keyboard. 
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Emulation Monitor 
Description 


Note 



This section applies to both foreground and background monitors 
except the user has no access to symbols or entry points in the 
background monitor. 


The emulation monitor is made up of the following major sections. 

■ The processor exception vector look-up table. 

■ The entry points into the monitor. 

■ The emulation command scanner. 

■ The command execution modules. 


Each of these sections is discussed in the following paragraphs. 

The Exception Vector The emulation foreground monitor is entered through processor 
Table exceptions. The emulation monitor program contains pseudo 
instructions that load the vector table with the addresses of the 
emulation monitor exception handlers. The emulation monitor 
exception table defines 68030 exception vectors for the 
convenience of the user. 

The emulation monitor program is shipped from the factory with 
all of the exception vectors (except RESET and MONITOR 
SINGLE STEP) contained in comment fields. This is done to allow 
you to supply the addresses for your own exception routines. If you 
have not written any exception handlers, you should remove the 
comment delimiters (*) from those provided in the monitor. This 
enables the processor to use the exception vector lookup table 
provided with the monitor program. 

If the user application has its own RESET handler, the reset vector 
in the monitor must be modified to point to the user reset handler. 
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Note f} 


Emulation Monitor 
Entry Point Routines 


Also, the reset-to-monitor function must be disabled. This is done 
by modifying the emulation configuration. You must answer no to 
the configuration question "Reset into the monitor?". See chapter 
4 for detailed information. 


The portion of the monitor defining the exception vector table is 
ORG’ed to OH, and is not relocatable as is the rest of the monitor. 
When configuring the emulator, be sure to map the first block of 
memory (OH) to supervisor_data emulation ram. Otherwise, locate 
the vector table in ROM in the target system. Refer to the section 
in this chapter titled "Loading the Emulation Monitor" for details 
on mapping the emulation monitor into memory. 


The emulation monitor entry point routines provide input handler 
routines for the various entry paths. Six separate paths are defined 
for monitor entry. Each path is distinguished from the others by 
means of a unique ENTRYID code which is stored upon entry 
into the monitor. The emulation monitor entry point routines are 
MONITOR_ENTRY, SWBK ENTRY, JSR_ENTRY, 
RESET_ENTRY, and EXCEPTION_ENTRY. 

Monltor_entry 

MONITOR ENTRY is the entry point into the emulation 
monitor for breaks from the user’s program. On a break to 
MONITOR_ENTRY, the 68030 PC and status register should be 
placed on the stack as is normally done when an exception occurs. 
On entry to the monitor, the processor’s registers are saved and the 
interrupt mask is restored (if you have modified your monitor to 
enable this function). The emulation monitor then executes the 
command scanner routines. 

Swbk_entry 

SWBK_ENTRY is the entry point into the emulation monitor 
when a software breakpoint (i.e., a BKPT instruction inserted in 
your code by the HP 64000-UX system) is processed. 
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Jsr_entry 

JSR_ENTRY (foreground monitor only) is the entry point into the 
emulation monitor that should be used if the user wants to jump 
directly to the emulation monitor. If running in supervisor mode, 
you can use the instruction "JSR JSR_ENTRY" to jump to the 
emulation monitor. If the 68030 processor is running in user mode, 
a trap exception should be used. The trap vector should point to 
MONITOR_ENTRY. 

Reset_entry 

RESET ENTRY is the entry point into the emulation monitor 
when the 68030 processes the reset exception. RESET_ENTRY 
sets up a default stack and sets the processor’s registers to default 
values. 

Exception_entry 

A set of exception entry points (foreground monitor only) are 
provided to give status messages for the ten exception vectors after 
reset. These exception vectors are provided for the convenience of 
the user and may be deleted or modified. For more information on 
the exception vector entry points, see the emulation foreground 
monitor source program and the section in this chapter entitled 
"Modifying The Exception Vector Table". 


Emulation Command The emulation command scanner normally rests in an idle loop 
Scanner labeled MONITORLOOP. The system global 

MONITOR CONTROL is repetitively examined. If bit 15 is set to 
zero, the idle loop is resumed. If bit 15 is set to one, a command is 
present and the program branches to the appropriate command 
routine. 

Bit 15 of MONITOR_CONTROL is set by the Host and cleared by 
the monitor program. The lower byte of MONITOR_CONTROL 
contains a command number against which the command table is 
compared. If a match is found, a command entry point will be 
retrieved from the table and the command will be executed. If a 
match is not found, the program will return to the idle loop. The 
command is considered complete when bit 15 of 
MONITOR_CONTROL is set to zero. 
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Emulation Command 
Execution Modules 


The Emulation Monitor command execution modules are 
ARE_YOU_THERE, EXIT_MONITOR, COPY_MEMORY, 
COPY ALT REG, MON ALT REGISTERS, 
SYNCH_START_ENABLE, SIM_INT_ENABLE, 
SIM_INT_DISABLE, and SIMULATED_INTERRUPT. 

Are_you_there 

ARE_YOU_THERE is used by the host (the HP 64000-UX) to 
determine whether the processor is executing in the monitor or in 
the target system code. It can also pass an ASCII message to be 
displayed on the host system status line. 

Exitmonitor 

EXIT_MONITOR reloads the processor’s register image and exits 
to the user’s program. 

Synch_start_enable 

SYNCH_START_ENABLE causes EXIT to be delayed. The 
monitor will loop waiting for an emulator status bit that indicates a 
synchronized start among multiple emulators has been received 
before EXIT is executed. This wait loop may be aborted by any 
command. 

C°py_memory 

COPY MEMORY moves data between the monitor parameter 
block areas and target system memory. This command is used to 
modify and display target system memory. 

C°py_alt_ re g 

COPY_ALT_REG reads from and writes to coprocessor registers. 

Mon_alt_reglsters 

MON_ALT_REGISTERS is a jump table which contains the 
address offset of the coprocessor register load/unload routine for 
each of the 8 possible coprocessors. 
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The MON_ALT_REGISTERS table should be set up to contain 
the load routine names - the table start. Offsets from the start of 
the table are stored so the entries will fit in 16 bits. 

Simint_enable 

SIMINT_ENABLE is a user defined simulated interrupt function 
which allows you to implement interrupt driven code on an 
emulator which is out of circuit. This command must set the local 
simulated interrupt enable flag TRUE and store 
SIM_INTS_TRUE at SIM_INT_CONTENTS to reenable 
simulated interrupts on exit. If simulated interrupts are not 
disabled on entry to the monitor, the break softkey will not work. 

Simint_disable 

SIMINT DISABLE is a user defined simulated interrupt function 
which allows you to disable interrupt driven code on an emulator 
which is out of circuit. This command must set the local simulated 
interrupt enable flag FALSE and store SIM_INTS_FALSE at 
SIM_INT_CONTENTS to keep simulated interrupts disabled on 
exit. If simulated interrupts are not disabled on entry to the 
monitor, the break softkey will not work. 

Simjnterrupt 

SIM_INTERRUPT is a user defined simulated interrupt function 
which allows you to implement interrupt driven code on an 
emulator which is out of circuit. This command will typically cause 
a branch to your interrupt handler by way of a trap instruction. 
When the command is complete, the host processor expects the 
processor to be in the monitor. 
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Customizing The 
Emulation Monitor 


Caution ■ possible loss of work session: 

W SYSTEM MAY BECOME UNUSABLE. Your customized portion 
of the emulation monitor must not exit the monitor program. 
Exiting the monitor will cause the entire system to become 
unsynchronized and, therefore, unusable. 

You should not make any changes to portions of the monitor other 
than those described in the following paragraphs. Changes in other 
sections of the monitor may cause some features to stop working 
due to modifications on the stack, or because the information that 
is passed to and from the various sections has been affected. 


For most systems, the emulation foreground monitor supplied with 
your emulator enables all emulation features to operate. Some 
systems, however, require modification to the emulation monitor 
program in order to maximize the effectiveness of the emulator. 
For this reason, the source program for the monitor has been 
provided and is thoroughly commented. Each of the standard 
routines within the code has been described so that you can easily 
make your modifications. 


Caution 



POSSIBLE LOSS OF ORGINAL MONITOR SOURCE 
PROGRAM! 

Do not modify original monitor source program. You should copy 
the 68030 emulation monitor source program to your subdirectory 
before making any modifications. Do not modify the copy supplied 
with your emulation system software. You should keep that copy 
as a backup. 
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If you haven’t already done so, copy the emulation monitor to your 
subdirectory by executing the following command: 


cp /usr/hp64000/monitor/mon_68030.s mon_68030.s 

You must execute the command "chmod 666 mon_68030.s" on the 
file before you modify it. It is shipped with "read-only" permissions. 

You should now modify the copy in your subdirectory. 


After modifying the monitor, be sure to reassemble and relink the 
monitor program. 
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Modifying The Find the following program block in the emulation monitor: 

Exception Vector 
Table. 


* ORG $000 

* DC .L SPJTEMP 

* DC.L RESET_ENTRY 

* 

* ORG $008 


0; reset 


2s bus error 


DC.L EXCEPTION ENTRY 


* ORG $00C 


3: address error 


DC.L EXCEPTION ENTRY 


* ORG $010 


DC.L EXCEPTION ENTRY 


4: illegal instruction 


* ORG $014 


DC.L EXCEPTION ENTRY 


5; divide by zero 


* ORG $018 


6: CHK instruction 


DC.L EXCEPTIONJENTRY 

ORG $01C 7: TRAPV 

DC.L EXCEPTION ENTRY 


* ORG $020 


DC.L EXCEPTION ENTRY 


8; privilege violation 


* ORG $024 


DC.L MONITOR ENTRY 


9: monitor single-step entry 


ORG $024 9: trace 

DC.L EXCEPTION ENTRY 


* ORG $028 


10: "A" Line 


DC.L EXCEPTION ENTRY 


* ORG $02C 


11: "F" Line 


DC.L EXCEPTION ENTRY 


* ORG $030 


DC.L EXCEPTION ENTRY 


12: unassigned and reserved by Motorola 


* ORG $034 


DC.L EXCEPTION_ENTRY 

ORG $038 14 : 

DC.L EXCEPTION ENTRY 


13: coprocessor protocol violation 


stack frame format error 


* ORG $03C 


DC.L EXCEPTION ENTRY 


15: uninitialized interrupt 


ORG $040 


DC.L EXCEPTION_ENTRY 
. other unassigned reserved entries 


16: unassigned and reserved by Motorola 


* ORG $05C 


DC.L EXCEPTION ENTRY 


23: unassigned and reserved by Motorola 


* ORG $060 


DC.L EXCEPTION ENTRY 


24: spurious interrupt 


* ORG $064 


25: interrupt level 1 autovector 


DC.L EXCEPTION ENTRY 


* ORG $068 


DC.L EXCEPTION ENTRY 


26: interrupt level 2 autovector 
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ORG $06C 27: 

DC.L EXCEPTION_ENTRY 

ORG $070 28: 

DC.L EXCEPTION_ENTRY 

ORG $074 29: 

DC.L EXCEPTION_ENTRY 

ORG $078 30: 

DC.L EXCEPTION_ENTRY 

ORG $07C 31: 

DC.L EXCEPTION__ENTRY 

ORG $080 32: 

DC.L EXCEPTION_ENTRY 

... other TRAP #n entries 

ORG $0BC 47: 

DC.L EXCEPTION_ENTRY 

ORG $0C0 48: 

DC.L EXCEPTION__ENTRY 

ORG $0C4 49: 

DC.L EXCEPTION_ENTRY 

ORG $0C8 50: 

DC.L EXCEPTION_ENTRY 

ORG $0CC 51: 

DC.L EXCEPT ION__ENTRY 

ORG $0D0 52: 

DC.L EXCEPTION_ENTRY 

ORG $0D4 53: 

DC.L EXCEPTION_ENTRY 

ORG $0D8 54: 

DC.L EXCEPTION JENTRY 

ORG $0DC 55: 

DC.L EXCEPTION_ENTRY 

ORG $0E0 56: 

DC.L EXCEPTION_ENTRY 

ORG $0E4 57: 

DC.L EXCEPTION ENTRY 


ORG $000 0: 

DC.L SPJTEMP 
DC.L RESET ENTRY 


interrupt 

interrupt 

interrupt 

interrupt 

interrupt 


level 3 autovector 
level 4 autovector 
level 5 autovector 
level 6 autovector 
level 7 autovector 


TRAP #0 


TRAP #15 


floating point coprocessor unordered condition 
floating point coprocessor inexact result 
floating point coprocessor divide by zero 
floating point coprocessor underflow 
floating point coprocessor operand error 
floating point coprocessor overflow 
floating point coprocessor signaling Not a Number 
unassigned and reserved by Motorola 
PMMU configuration error 
PMMU illegal operation 


Now, using your editor, remove the comment delimiters (*) from 
the start of each line of code (except the second ORG $24 
statement) to make your program look as follows: 

reset 


ORG $008 2: 

DC.L EXCEPTION ENTRY 


bus error 


ORG $00C 3: address error 

DC.L EXCEPTION__ENTRY 

ORG $010 4: illegal instruction 

DC.L EXCEPTION ENTRY 
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ORG $014 5: divide by zero 

DC.L EXCEPTION_ENTRY 

ORG $018 6: CHK instruction 

DC.L EXCEPTION_ENTRY 

ORG $01C 7: TRAPV 

DC.L EXCEPTION_ENTRY 

ORG $020 8: privilege violation 

DC.L EXCEPTION_ENTRY 

ORG $024 9: monitor single-step entry 

DC.L MONITOR ENTRY 


ORG $024 9: trace 

DC.L EXCEPTION_ENTRY 

ORG $028 10: "A" Line 

DC.L EXCEPTION ENTRY 


ORG $02C 11: "F" Line 

DC.L EXCEPTION_ENTRY 

ORG $030 12: unassigned and reserved by Motorola 

DC.L EXCEPTION ENTRY 


ORG $034 13: coprocessor protocol violation 

DC.L EXCEPTION_ENTRY 

ORG $038 14: stack frame format error 

DC.L EXCEPTION ENTRY 


ORG $03C 15: uninitialized interrupt 

DC.L EXCEPTIONENTRY 

ORG $040 16: unassigned and reserved by Motorola 

DC.L EXCEPTION ENTRY 


. .. other unassigned reserved entries 


ORG $05C 23: unassigned and reserved by Motorola 

DC.L EXCEPTION_ENTRY 

ORG $060 24: spurious interrupt 

DC.L EXCEPTION ENTRY 


ORG $064 

DC.L EXCEPTION_ 

25: 

ENTRY 

interrupt 

level 

1 

autovector 

ORG $068 

DC.L EXCEPTION_ 

26: 

ENTRY 

interrupt 

level 

2 

autovector 

ORG $06C 

DC.L EXCEPTION_ 

27: 

ENTRY 

interrupt 

level 

3 

autovector 

ORG $070 

DC.L EXCEPTION^ 

28: 

ENTRY 

interrupt 

level 

4 

autovector 

ORG $074 

DC.L EXCEPTION_ 

29: 

ENTRY 

interrupt 

level 

5 

autovector 

ORG $078 

DC.L EXCEPTION_ 

30: 

ENTRY 

interrupt 

level 

6 

autovector 

ORG $07C 

DC.L EXCEPTION 

31: 

ENTRY 

interrupt 

level 

7 

autovector 

ORG $080 

DC.L EXCEPTION 

32: 

ENTRY 

TRAP #0 





. . . other TRAP #n entries 
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ORG $0BC 47i 

DC . L EXCEPT ION__ENTRY 

ORG $0C0 48 i 

DC.L EXCEPTION_ENTRY 

ORG $0C4 49i 

DC.L EXCEPT ION_jENTRY 

ORG $0C8 50: 

DC.L EXCEPTION_ENTRY 

ORG $0CC 51: 

DC.L EXCEPTION_ENTRY 

ORG $0D0 52: 

DC.L EXCEPTION_ENTRY 

ORG $0D4 53: 

DC.L EXCEPT ION__ENTRY 

ORG $0D8 54: 

DC.L EXCEPTION_ENTRY 

ORG $0DC 55: 

DC.L EXCEPTION_ENTRY 

ORG $0E0 56: 

DC.L EXCEPTION_ENTRY 

ORG $0E4 57: 

DC.L EXCEPTION ENTRY 


TRAP #15 

floating point coprocessor unordered condition 
floating point coprocessor inexact result 
floating point coprocessor divide by zero 
floating point coprocessor underflow 
floating point coprocessor operand error 
floating point coprocessor overflow 
floating point coprocessor signaling Not a Number 
unassigned and reserved by Motorola 
PMMU configuration error 
PMMU illegal operation 


End out of your edit session, making sure that you save your 
changes. 

By removing the comment delimiters from this section of the 
monitor, you have made the exception vector table usable. The 
table provides all addresses that the monitor needs to operate. 


Emulation Monitor 7*17 



Continuing Target 
System Interrupts 
While In The 
Emulation Monitor 


The processor interrupt mask can be restored to its prebreak value 
to enable target system interrupts while in the monitor. You must 
edit the monitor program if you want to enable the interrupts while 
running in the emulation monitor. 


Under the MONITOR JiNTRY label, you will find a commented 
section that describes re-enabling the interrupts. 


MONITOR_ENTRY 

* return from exception if already in the monitor 

TAS MONITOR_SE MAPHORE 

BPL.B BREAK_OK 

RTE 

BREAK__OK 

* block interrupts 

ORI.W #BLOCK INTERRUPTSCINT MSK SHIFT,SR 


Comment the instruction ORI.W 

#BLOCK_INTERRUPTS < INT_MSK_SHIFT,SR to use the 
interrups while in the monitor. Be sure to save your changes. 


Sending Messages 
From the User 
Program To the 
Emulator Display 


Note 



This option is only available with the foreground monitor. 


The PUT_MONITOR_MSG routine in the emulation monitor 
gives you a way to send messages to the display status line. In order 
to use this feature, you must do the following steps: 

1. Define the message in your user code. 

2. Set a trap vector to point to the PUT_MONITOR_MSG 
routine. 
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3. Initiate the appropriate trap. This will cause a "message 
breakpoint" and leave the processor running in the 
emulation monitor. 

4. If you want to continue execution of your user program, 
your program should pop one long word off the stack to 
clean up the stack after the trap. 


An example program implementing the "message breakpoint" is 
shown below. 





★ 


PUT__MONITOR_MSG is entered if you set up a trap vector 
to point to it. The purpose of PUT__MONITOR__MSG is to send a 
monitor message to the emulator, even if the request is not 
in supervisor space. 

The protocol for using PUT_MONITOR_MSG is as follows; 

1) Set a TRAP #n vector to point to PUT_MONITOR_MSG. 

2) Push the address of the message onto the stack. 

The message must be in data space. 

3) Initiate the appropriate trap. This will cause a 
"message breakpoint", and leave the processor running 
in the monitor. 

4) If you continue the run, your program should pop 
one long word off the stack to clean up. 




PUT_MONITOR_MSG 

* return from exception if already in the monitor 
TAS MONITOR_SEMAPHORE 

BPL. B PUT__MON_MSG_OK 

RTE 



PUT MON_MSG_OK 
* bTock interrupts 

ORI.W #BLOCK INTERRUPTS<INT MSK SHIFT,SR 


* save registers 

MOVEM.L D0-D7/A0-A6,PREGS 

MOVEC SFC,AO 

MOVE . L AO , SFC__REG 

MOVEC DFC,AO 

MOVE.L AO,DFC_REG 


* read emulator status register 

MOVEQ #FC__CPU_SPACE, DO 

MOVEC DO,SFC 

MOVEC DO,DFC 

MOVES.L EMUL_STATUS,DO 

* clear low in_jnonitor bit 

BCLR #LINMON,DO 

MOVES. L DO , EMUL__STATUS 
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* if a supervisor space break (- 8 because memory reference BTST is a byte op) 

BTST #SUPRVISOR_STATE-8,(SP) 

BEQ. B USER_FRAME 

PUT_MON_MSG_l 

* put supervisor data function code into message parameter area 

MOVE . L # FC_SUPER_DATA f MON_MSG_FC 

* save message address from below trap frame on stack 

MOVE.L (FOUR_WORD_SIZE* 2,SP),MONITOR_ME SSAGE 

BRA.B FINISH_MESSAGE 

USER_FRAME 

* else stack is in user data space 

* put user data function code into message parameter area 

MOVE.L # FC_USER_DATA,MON_MSG_FC 

* get user stack pointer 

MOVE.L # FC_USER_DATA,DO 

MOVEC DO,SFC 

MOVE USP,AO 

* save message address from top of stack 

MOVES.L (AO),DO 

MOVE.L DO ,MONITOR_MESSAGE 

FINISHMESSAGE 

* set message pending bit and set why_there to MON_MSG_RECVD 

MOVEQ #FC_CPU_SPACE,DO 

MOVEC DO,SFC 

MOVEC DO,DFC 

MOVES.W MONITOR_CONTROL,DO 

BSET #MON_MSG_PEND,DO 

MOVEQ #MON_MSGJRECVD,D1 

BFINS D1, DO {WHY_THEREDSTART: WHY_THERE_W IDTH } 

MOVES.W DO,MONITOR_CONTROL 

BRA.W MONITORMAIN 

it******************************************************************************* 
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Emulation Monitor 
Memory 

Requirements For 
The 68030 


The memory available in the emulation hardware is divided into 
256-byte blocks of address space by the emulation system. Each 
256-byte block begins on an even address multiple of 100H. 

The relocatable program area of the emulation monitor requires 
approximately 3900 bytes of memory. You can determine this if 
you look at the MODULE SUMMARY section of the linker listing 
file (see below). You can see, in this example, that the emulation 
monitor begins at address 100H and ends at address 1023H. The 
program takes up 0A6B hexadecimal locations of memory. The 
value 0F23H is approximately 3900 decimal. Therefore, the 
emulation monitor can be mapped into 16 256-byte blocks of 
memory. 


MODULE SUMMARY 


MODULE 

SECTION:START 

SECTION:END 

FILE 

mon_68030 

9:00000000 

9:00000000 

/hp/emul32/processor/m68030 


mon_prog:00000100 

mon_prog:00000B6B 

/monitor/mon_68030.o 


mon_data:00000B6C 

mon_data:00001023 



:00000024 

:00000027 



These memory requirements assume that the blocks each start on a 
256-byte boundary and that the standard emulation monitor is 
being loaded. To check the memory requirements for the 
emulation monitor being used, the linker listing file should be 
checked. 

The monitor program must reside in supervisor space. See the 
section "Loading The Emulation Monitor" in this chapter for 
details. 
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Linking The 
Emulation 
Foreground 
Monitor 


Loading The 
Emulation Monitor 


The emulation foreground monitor must be assembled and linked 
before it can be used by the emulation system. It can be linked with 
the target system code to produce one absolute file or it can be 
linked by itself. 


The following rules must be followed when loading the emulation 
monitor: 

1. Data space of the monitor must be mapped as RAM as 
opposed to ROM. The monitor transfer buffer, as well as 
many monitor "housekeeping" variables must be read and 
write accessible, and must, therefore be mapped as RAM. 

In addition, portions of the monitor must write to other 
monitor program locations. Since writes to ROM are 
always blocked, the program section, as well as the data 
section, of the monitor must be mapped to RAM. 

2. The emulation monitor is executed in response to a level 7 
interrupt. Therefore, it is always executed within 
supervisor space and must be located in supervisor space. 
If the supervisor/user function code bit is not in use, this 
restriction does not apply. 

The emulation software recognizes only program symbols. In the 
case of the monitor, the symbol addresses are assumed to be 
associated with the SUPR_PROG function code (since the 
monitor is basically an interrupt routine). When the host writes 
control information to, or reads information from the monitor, it 
must use the special data spece located in CPU space. 
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Using Reset Into 

Foreground 

Monitor 


If reset into the foreground monitor is specified as an option 
during emulation configuration (refer to chapter 4), some memory 
- either target or emulation - must be mapped to OH SUPR_PROG. 
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Notes 
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Using Custom Coprocessors 


Overview 



This chapter provides the following information: 

■ A discussion of the requirements for using custom 
coprocessors. 

■ A detailed description of the custom coprocessor format 
file. 

■ A detailed description of how to modify the emulation 
monitor for use with custom coprocessors. 

■ A description of the emulation configuration questions 
related to custom coprocessors. 


Introduction 


Custom register access is only supported with the foreground 
monitor enabled, except in the case of the MMU registers. MMU 
registers display and modification are supported for both 
foreground and background monitors. 


Note 


« 



The 68030 emulator has the capability to access floating point 
coprocessors and other coprocessors in your target system. You 
can both display and modify coprocessor register sets. 
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In order to use custom coprocessors with the emulator, you must: 

B Provide a custom register format file defining the 
coprocessor address, size, and name and defining the 
register display format. 

■ Modify the emulation monitor program to include a 
storage buffer for the coprocessor registers, read/write 
routines to access coprocessor registers, and a pointer to 
the coprocessor read/write routines. 

■ Specify the custom register format file to the emulator 
during emulation configuration. 

An example custom register format file is provided with your 
emulation software. This file is named: 

/usr/hp64000/inst/emul32/0410/0204/custom__spec. 

Read/write routines for the MMU are provided in the emulation 
monitor program. 
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The Custom 
Register Format 
File 


A custom register format file must specify the coprocessor you 
want to use with emulation. This file specifies: 


■ Which coprocessors should be used. 

■ Which coprocessor space the coprocessors should be 
located in. 

■ How large the register buffer should be for transfers. 

■ What the display should look like for each coprocessor. 

■ What register names there are for register modifies. 

This file is read when the emulation configuration file is processed. 
The custom register format specification is fairly simple. For each 
coprocessor register set defined in the file, the following items 
must appear in the order specified: 

1. the coprocessor address 

2. the coprocessor size 

3. the coprocessor name 

4. the display spec 

You may place comments in C language format (enclosed by "/*" 
and "*/") or blank lines before or after any register set, as well as 
between the specification fields. You can specify C language format 
include files using a control line of the form: 

#include "filename” 
or 

#include < filename > 

where the register set description could be placed in the include 
file. Filename must be the full pathname for the include file. 
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Address Specification 


Size Specification 


Name Specification 


Using include files simplifies your custom register specification file 
and allows you to easily remove a register set from the specification 
file, if necessary. 

A listing of a sample custom register specification file is shown in 
figure 8-1 at the end of this section. Figures 8-2 and 8-3 show how 
the same file could be written using a sample include file and 
include command lines. 

The address specification is of the form: 

ADDR=n 

where n is the coprocessor identification code that defines the 
coprocessor space. The address must be a number between 0 and 7, 
inclusive. If two register sets in the format file have the same 
address, only the last specified register set is used. The first register 
set is ignored. ADDR 0 is reserved for the MMU. The address 
specified for the "fpu" coprocessor must match the external FPU 
coprocessor identification code. 

The size specification is of the form: 

SIZE=n 

where n is the size (in bytes) of the register set transfer buffer. The 
transfer buffer is used to transfer the register contents between the 
emulation monitor and the host system. This number must be 
between 0 and 1020, inclusive. 

The coprocessor name specification is of the form: 

NAME="string" 

where string is a unique name for the coprocessor. If the name is 
not unique, any previous register specs with the same name will be 
ignored. The string must only contain alphanumeric characters. 
Register set names are available on softkeys during display, copy, 
and modify commands. Register set names are also placed in the 
header of the register display if the coprocessor set is active during 
the display. 
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Register Set Display 
Specification 


The register set display specification is enclosed by two lines as 
follows: 

DISPLAY_START 

< display specification > 

DISPLAY_END 

The DISPLAY_START and the DISPLAY_END lines cannot 
have any trailing blanks. Any statements within these lines are used 
to generate the register display. These lines also provide 
information to the emulator for setting up register names for the 
modify command. Register specifications have the form: 

NAME %OFFSET.WIDTH 

where: NAME is the name that the register should be 

referenced by during display and modify 
commands. 

OFFSET is the index into the register buffer 
(in bytes) to the iocation of the register contents. 

WIDTH is the register width (in bytes). 

All other text and white space in the register specification is 
presented in the display exactly as specified in the format file. 
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/*************************************************/ 

/* */ 

/* COPROCESSOR DISPLAY FORMAT SPECIFICATIONS */ 

/* */ 

/*****************************★****★*************★/ 

/* This file contains the display format specifications for all coprocessors */ 
/* configured for this system. It may contain up to 7 other coprocessor */ 

/* specifications. */ 

/* */ 

/* The entry below describes the format for an 68882 fpu, and is used */ 
/* as an example. There are several pieces of data which MUST be supplied */ 
I* for each specification; */ 

/* */ 

/* ADDR=n f where n is in the range 0-7. This is the coprocessor id-code */ 

/* for the current entry. Please note that ADDR=0 is reserved for */ 

/* the MMU, and that all ADDR designations should appear only */ 

/* once in this file. */ 

/* */ 

/* SIZE=n, where 0 < n < 1020 bytes. SIZE describes the number of bytes */ 

/* in the monitor register buffer the user has defined for this */ 

/* coprocessor. */ 

/* */ 

/* NAME="string", where "string" is the UNIQUE name of the current */ 
/* coprocessor. The name is made up of alphanumeric characters */ 

/* only. This name will show up on a softkey when */ 

/* attempting to display/modify registers within emulation. */ 

/* */ 

/* DISPLAY_START marks the start of the display format spec for the */ 
/* current coprocessor. */ 

/* */ 

/* DISPLAYEND marks the end of the display spec, and also the end */ 

/* of the information for the current coprocessor. A new speci- */ 

/* fication may follow each DISPLAY END. */ 

/* */ 

/* Within the bounds of DISPLAYSTART and DISPLAYEND is the information */ 

/* needed to generate the display for each coprocessor. Each register */ 

/* description contains a name field and a register format field. The format */ 

/* field is in the form: */ 

/* */ 

/* %OFFSET.WIDTHr, where OFFSET is the index into the register buffer */ 

/* defined in the monitor (in bytes), and WIDTH is the width of */ 

/* the register (also in bytes). All other text, white space, */ 

/* etc, are preserved in the display. */ 


Figure 8-1. Sample Custom Register Specification File 
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/*****★******★**********************★/ 
/* */ 

/* EXAMPLE 68882 FPU SPECIFICATION */ 
/* * / 

/*****★***★*********★★★★**★★★★★★*★*★*/ 


ADDR=1 
SIZE=108 
NAME="fpu" 


/* the fpu id-code (special: set by configuration) */ 
/* number of bytes in the fpu register buffer */ 

/* name of the fpu coprocessor (do not change) */ 


DI SPLAY__START 
FPO %00.12r 
FP2 %24.12r 
FP4 %48.12r 
FP6 %7 2.12r 


FP1 %12.12r FPCR %96.4r 
FP3 %36.12r FPSR %100.4r 
FP5 %60.12r FPIAR %104.4r 
FP7 %84.12r 


DISPLAY END 


/* Other custom coprocessor display formats follow... */ 


Figure 8-1. Sample Custom Register Spec. File (Cont’d) 






/* */ 
/* EXAMPLE 68882 FPU SPECIFICATION */ 


/* 


*/ 


ADDR=1 /* the fpu id-code (special: set by configuration) */ 

SIZE=108 /* number of bytes in the fpu register buffer */ 

NAME="fpu" /* name of the fpu coprocessor (do not change) */ 


DISPLAY_START 

FPO %00.12r 
FP2 %24.12r 
FP4 %48.12r 
FP6 %72.12r 

DISPLAY END 


FP1 %12.12r FPCR %96.4r 
FP3 %36.12r FPSR %100.4r 
FP5 %60.12r FPIAR %104.4r 
FP7 %84.12r 


Figure 8-2. Custom Reg. Spec. Include File fpu_spec 
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/************★**************★**★*****★***★********/ 

/* COPROCESSOR DISPLAY FORMAT SPECIFICATIONS */ 

/* */ 
/*************************************************/ 

/* This file contains the display format specifications for all coprocessors */ 
/* configured for this system. It may contain up to 7 other coprocessor */ 

/* specifications. */ 

/* */ 

/* The entry below describes the format for an 68881 fpu, and is used */ 
/* as an example. There are several pieces of data which MUST be supplied */ 

/* for each specification: */ 

/* */ 

/* ADDR=n, where n is in the range 0-7. This is the coprocessor id-code */ 

/* for the current entry. Please note that ADDR=0 is reserved for */ 

/* the MMU, and that all ADDR designations should appear only */ 

/* once in this file. */ 

/* */ 

/* SIZE=n, where 0 < n < 1020 bytes. SIZE describes the number of bytes */ 

/* in the monitor register buffer the user has defined for this */ 

/* coprocessor. */ 

/* */ 

/* NAME="string", where "string" is the UNIQUE name of the current */ 
/* coprocessor. The name is made up of alphanumeric characters */ 

/* only. This name will show up on a softkey when */ 

/* attempting to display/modify registers within emulation. */ 

/* */ 

/* DISPLAY_START marks the start of the display format spec for the */ 
/* current coprocessor. */ 

/* */ 

/* DISPLAY_END marks the end of the display spec, and also the end */ 
/* of the information for the current coprocessor. A new speci- */ 

/* fication may follow each DISPLAYEND. */ 

/* */ 

/* */ 

/* Within the bounds of DISPLAYSTART and DISPLAY_END is the information */ 

/* needed to generate the display for each coprocessor. Each register */ 

/* description contains a name field and a register format field. The format */ 

/* field is in the form: */ 

/* */ 

/* %OFFSET.WIDTHr, where OFFSET is the index into the register buffer */ 

/* defined in the monitor (in bytes), and WIDTH is the width of */ 

/* the register (also in bytes). All other text, white space, */ 

/* etc, are preserved in the display. */ 

♦ include "/users/em68030/custom_spec/fpu__spec" 


Figure 8-3. Custom Reg. Spec. File Using Include Files 
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Emulation Monitor 
Changes 


Defining a 
Coprocessor 
Register Buffer 


In order to access coprocessor register sets, you must make some 
minor changes to the emulation monitor. You must declare a 
register buffer for storing the coprocessor register values, modify 
two table entries, and provide register buffer read/write routines 
for each coprocessor register set that the emulation monitor will 
access. 

A coprocessor register buffer must be allocated in the emulation 
monitor for each custom coprocessor you use with the emulator. 
The emulator uses this buffer for storing register values read from 
or written to the custom coprocessor. An example buffer 
(MMU_REGS) is provided with the emulation monitor program. 
This buffer is declared in the emulation monitor as follows: 


MMU REGS 
SRP_REG 

DC . L 

0 


DC. L 

0 

CRP_REG 

DC . L 

0 


DC . L 

0 

TC REG 

DC . L 

0 

TTO REG 

DC . L 

0 

TT1 REG 

DC . L 

0 

MMUSR REG 

DC .W 

0 


Locate this declaration in the emulation monitor program and 
insert your custom coprocessor register buffer declarations 
immediately following it in the emulation monitor. For example, if 
you are using an MC68882 coprocessor in your target system, you 
might add the following register buffer declaration: 


FPU 882 REGS 

FP REG 

DS.L 

24 

CONTROL REG 

DC . L 

0 

STATUS REG 

DC . L 

0 

IADDR REG 

DC .L 

0 

FPU 882 END 
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Modifying The 
MON CPU_REG- 
ISTERS Table 


After declaring your register buffers, you need to modify the 
MON_CPU_REGISTERS table. This table has entries labeled 
"COPROC_REG_n", where n is the coprocessor identification 
number. The coprocessor identification numbers specified in the 
format file must have their corresponding table entry set to point 
to a buffer that will be used to transfer the register data to and 
from the monitor. These are the buffers that you declared in the 
previous section. The default MON_CPU_REGISTERS table 
provided with your emulation monitor is shown in the following 
listing: 


MON CPU REGISTERS 


COPROC_REGO DC.L 
COPROC_REG_l DC.L 
COPROC_REG_2 DC.L 
COPROCREG3 DC.L 
COPROCREG4 DC.L 
COPROC_REG_5 DC.L 
COPROC_REG_6 DC.L 
COPROC REG 7 DC.L 


MMU_REGS 

0 

0 

0 

0 

0 

0 

0 


For example, if you want to add an FPU in your target system at 
coprocessor address 1, you might want to modify the 
MON_CPU_REGISTERS table as follows: 


MON CPU REGISTERS 


COPROCREGO DC.L 
COPROC_REG_1 DC.L 
COPROC_REG_2 DC.L 
COPROC__REG_3 DC. L 
COPROC_JREG 4 DC.L 
COPROC_REG~5 DC.L 
COPROC__REG__6 DC. L 
COPROC REG 7 DC.L 


MMU851REGS 

FPU882REGS 

0 

0 

0 

0 

0 

0 
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Modifying The 
MON_ALT_REGISTERS 
Table 


Writing Coprocessor 
Copy Routines 


The second table you must change is under the symbol 
f, MON_ALT_REGISTERS". This table has entries labeled 
"COPROCLOADn", where n is the coprocessor identification 
number. These entries point to a coprocessor’s read/write routine. 
An example read/write routine (FPU_881_COPY) is provided in 
the emulation monitor for use with an external FPU. The default 
MON_ALTJREGISTERS table provided with your emulation 
monitor is shown in the following listing: 


MON ALT REGISTERS 


COPROC_LOAD_0 DC.W 
COPROC_LOAD_l DC.W 
COPROC_LOAD_l DC.W 
COPROC__LOAD__2 DC . W 
COPROC_LOAD_3 DC.W 
COPROC_LOAD_4 DC.W 
COPROC_LOAD__5 DC. W 
COPROC_LOAD_6 DC.W 
COPROC LOAD 7 DC.W 


MMU_COPY-MON_ALT_REGISTERS 
INVALID_CP_ID-MON_ALT_REGISTERS 
INVALID__CP__ID-MON__ALT__REGI STERS 
INVALI D_CP_I D-MON_ALT_REG I STERS 
INVALID_CP_ID-MON_ALT_REGISTERS 
INVALID_CP_ID-MON_ALT_REGISTERS 
INVAL I D_CP_I D-MON_ALT__REG I STERS 
INVALID_CP_ID-MON_ALT_REGISTERS 
INVALID CP ID-MON ALT REGISTERS 


If you want to use a FPU in your target system as in the previous 
example, you would modify the MON_ALT_BUFFER table as 
follows: 


MON ALT REGISTERS 


COPROC_LOAD_0 DC.W 
COPROC__LOAD_l DC. W 
COPROC__LOAD_l DC . W 
COPROC_LOAD_2 DC. W 
COPROC_LOAD_3 DC . W 
COPROC_LOAD_4 DC.W 
COPROC_LOAD__5 DC . W 
COPROC JLOAD_6 DC . W 
COPROC LOAD 7 DC.W 


MMU_COPY-MON_ALT_REGISTERS 
FPU_8 8 2_COPY-MON_ALT_REGISTERS 
INVALID_CP_ID-MON_ALT_REGISTERS 
INVALID_CP_ID-MON_ALT_REGISTERS 
INVALID_CP_ID-MON_ALT_REGISTERS 
INVALI D_CP_I D-MON_ALT_REG I STERS 
INVALID__CP_ID-MON_ALT_REGISTERS 
INVAL I D_CP__ID-MON__ALT_REGI STERS 
INVALID CP ID-MON ALT REGISTERS 


where FPU_882_COPY is the copy routine you have written for 
your FPU registers. 

The coprocessor copy routine must both read from and write to the 
coprocessor registers. If the emulation monitor symbol 
"MON_COMMAND H contains the value ”6", then the routine 
should perform a read into the register data buffer specified above. 
If the symbol = 7, the routine should write the register set using 
the values in the register data buffer. 
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Answering 
Emulation 
^ Coprocessor 
Configuration 
Questions 


After modifying the emulation monitor, you must reassemble the 
emulation monitor and relink your emulation monitor with your 
user file. 

The final step in setting up your 68030 emulator to use custom 
coprocessors is to answer the emulation configuration questions 
relating to custom coprocessors. In the default emulation 
configuration, you will be asked the question: 

Any custom registers? 

Answer yes to enable use of custom coprocessors. 

If you answered "yes" to the above question, the next question will 
be: 

Name of custom register format file? 


Enter the full pathname of your custom register format file. 



Complete the remainder of the emulation configuration questions 
and save your changes to a configuration file. You are now ready to 
run emulation using custom coprocessors. 

A complete and detailed description of the emulation 
configuration questions is given in chapter 4. 
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Using Simulated I/O And Simulated Interrupts 


Overview 



This chapter provides the following information: 

■ A description of how to configure simulated I/O, with a 
section on simulated I/O restrictions. 

■ A discussion of simulated interrupts which includes: 

- How simulated interrupts functions. 

- Simulated interrupts versus real interrupts. 

- Simulated interrupt configuration. 

■ A description of how to modify the monitor to use 
simulated interrupts. 


Note B Simulated I/O will work with either the foreground or the 

™ background monitor. Simulated interrupts will work only with the 

foreground monitor. When the MMU is enabled, all addresses 
used for the simulated I/O configuration must be mapped 
transparently. In a target system, it is expected that I/O space will 
be mapped transparently. 
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Configuring 
Simulated I/O 


The simulated I/O subsystem must be set up by answering a series 
of configuration questions. Your answers to these questions enable 
simulated I/O, set the control addresses, and define files used for 
standard I/O. 

Detailed information on using simulated I/O with the emulator is 
provided in the HP 64000-UX Simulated I/O Rtf erence Manual. 

Modify simulated I/O configuration? yes (no) 

no Answering no causes the simulated I/O questions to be 
skipped. The current simulated I/O configuration is not 
modified. 

yes Answering yes enables you to modify the simulated I/O 
configuration. The following questions are asked. 

Enable polling for simulated I/O? no (yes) 

no Prevents the emulation software from reading the control 
address for simulated I/O commands. Answering no to this 
question enables you to disable simulated I/O while 
maintaining the current simulated I/O configuration. 

Later, when you need to enable simulated I/O, you can do 
so without having to re-enter control addresses or the file 
names for standard input, standard output, and standard 
error output. Answering no also causes the remaining 
simulated I/O questions to be skipped. 

yes Causes the emulation software to frequently read the 
control address to determine if the user program has 
requested any simulated I/O commands. Answering yes 
causes the following questions to be asked. 

Function code data space? none (SUP_DATA) (USR_DATA) 

This question asks you to specify the data space where the simio 
control addresses are located. 

If during memory configuration, you specified modify 
defined_codes none, you should use the default answer (none) here. 
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If you specified modify defined_codes all, you should select 
SUP_DATA or USR_DATA as appropriate for your system. 

If you specified modify defined_codes prog data, you should select 
USR_DATA. 

Simio control address 1? SIMIO_CA_ONE (<Addr>) 

Simio control address 2? SIMIO_CA_TWO (< Addr>) 

Simio control address 3? SIMIO_CA_THREE (< Addr>) 

Simio control address 4? SIMIO_CA_FOUR (<Addr>) 

Simio control address 5? SIMIO_CA_FIVE (<Addr>) 

Simio control address 6? SIMIO_CA_SIX (<Addr>) 

The symbol SIMIO_CA_ONE is the default symbol associated 
with the first simulated I/O Control Address. The default symbol 
may be replaced with any valid symbol or an absolute address. If a 
symbol is specified, polling of that control address will not begin 
until a file containing that symbol is loaded. If an absolute address 
is specified, polling of that address will begin immediately. 

The control address must be loaded into memory space assigned as 
RAM. User programs will run faster if the control address is 
located in emulation memory. Using target RAM causes the 
emulator to break into the monitor program every time the control 
address is polled for simulated I/O commands or data. 

The following questions relate to the files associated with the three 
reserved file names "stdin", "stdout", and "stderr". 

File used for standard input? /dev/simio/keyboard (<FILE>) 

File used for standard output? /dev/simio/display (<FILE>) 

File used for standard error? /dev/simio/display (<FILE>) 

The default answers for these questions are "/dev/simio/keyboard”, 
"/dev/simio/display", and "/dev/simio/display" respectively. 

These files are not opened until Open (90H) is called with the file 
names "stdin", "stdout", and "stderr". These files are provided to 
allow easy redirection of input and output from the keyboard or 
display to a file or device without modifying the user program. 

(The compiler standard I/O libraries may open some or all of these 
reserved files automatically if simulated I/O is used. For more 
details, see the documentation on the simulated I/O libraries for 
the compiler you are using.) 
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Restrictions On Restrictions on the use of simulated I/O are: 

Simulated I/O 


B There is a limit of 12 open files at any one time. 

B There can only be four active simulated I/O processes at 
any one time. 

B When using MMU, all simulated I/O control addresses 
must be mapped 1:1. 

u When using MMU, the memory for simulated I/O must 
always be accessible from the supervisor state of the 
processor. 


Since any simulated I/O file that is opened is associated with a file 
descriptor, opened files are independent of the control address. Up 
to 12 files can be opened with a single control address (CA). A 
total of six control addresses are allowed so that you can execute 
simulated I/O commands concurrently. Remember, a maximum of 
12 simulated I/O files (between the six control addresses) may be 
open at any one time. 
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Simulated 

Interrupts 


How Does A 
Simulated Interrupt 
Function? 


Simulated interrupts enable you to test software which depends 
upon the occurrence of preemptive interrupts using out-of-circuit 
emulation. The simulated interrupt facility is enabled by writing a 
value of Offh to the simulated interrupt control address. The 
control address is defined during the emulation configuration 
session. The simulated interrupt facility, when enabled, generates 
approximately six interrupts per second, depending on what other 
emulation activities are occurring concurrently, i.e., simulated I/O 
and display updates. 

The simulated interrupt facility can be used to test applications 
such as a preemptive scheduler in a multitasking system or 
interrupt driven I/O. Interrupt driven I/O can be simulated by 
executing simulated I/O commands when a simulated interrupt 
occurs. 

An interrupt is a request by an external device that causes the 
processor to temporarily suspend normal execution in order to 
service the interrupting device. Normal execution resumes after the 
device has been serviced. Interrupts are asynchronous to normal 
execution. To simulate this action out of circuit, the emulation 
software running on the host system acts as the external device 
requesting service. 


There are only two ways that the emulation software can interrupt 
the emulator. The first is to reset the processor in the emulator. 
Since a reset causes the current instruction counter to be lost, 
continuation of program execution is not possible. Therefore, reset 
is not usable for simulated interrupts. The second way to interrupt 
the emulator is to break to the monitor. This is the method used to 
implement simulated interrupts. Therefore, the emulation monitor 
must be loaded in order to use simulated interrupts. 

The simulated interrupt begins when a value of Offh is written into 
the simulated interrupt control address. The emulation software 
polls this address just as it polls simulated I/O control addresses. 
When emulation finds the value Offh at the simulated interrupt 
control address, it causes a break to the emulation monitor. 
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Simulated Interrupts 
Versus Real Interrupts 


The emulation monitor saves all registers as a normal part of the 
monitor entry sequence. The emulation monitor then loops, 
waiting for a command. The emulation software then sends a 
simulated interrupt command to the emulation monitor. The 
emulation monitor supplied with the emulator contains only a stub 
which immediately indicates completion. 

However, a simulated interrupt is user definable. To create your 
own simulated interrupt, you must modify the emulation monitor. 
The modification must include the interrupt code needed to 
perform the action you want to happen when an interrupt occurs. 
Be aware of the time constraints discussed in the following section 
"Simulated Interrupts Versus Real Interrupts". A typical action is 
a TRAP instruction which vectors to your interrupt handler. See 
the example program given in figure 9-1. This feature is not 
available without modifying the monitor. For information on 
modifying the monitor for simulated interrupts, refer to the section 
of this chapter entitled "Modifying the Monitor to Use Simulated 
Interrupts". 

Finally, after the interrupt is serviced, emulation sends the exit 
monitor command to the emulation monitor. The exit monitor 
command restores the registers that were saved upon entry to the 
monitor, which causes normal program execution to continue at 
the point where it was interrupted. 


There are some important differences between simulated 
interrupts and real interrupts. A simulated interrupt handler must 
return within a fixed amount of time. Part of the simulated 
interrupt configuration is the specification of the maximum 
amount of time that emulation should wait for an interrupt handler 
to complete execution. If the interrupt handler does not complete 
within the specified time, emulation forces a break to the monitor, 
reports a failure, and causes the simulated interrupt to terminate. 

It is not al ways possible to wait for simulated I/O to complete an 
interrupt handler. 
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* This is a simulated interrupt test program. The vector for 

★ 

* TRAP #14 is pointed to 

INT HANDLER. The 

SIM INTERRUPT command 

★ 

* of the monitor 

must be 

modified to execute a TRAP #14. Notice 

★ 

* that the SMIINT CA is enabled, then a delay loop is executed, 

★ 

* then SIMINT CA 

is disabled. INT HANDLER 

increments the location 

* 

* COUNTER to provide a count of the number 

of interrupts tha occurred. 

★ 

* 


NOTE 


* 

* Simulated interrupts must be enabled in the emulator configuration 

★ 

* and the control 

address 

must be set to SIMINT CA. To observe the 

* 

* number of interrupts occuring, use the following command: 

* 

★ 

* display memory 

COUNTER 

thru COUNTERS7 blocked long repetitively 

* 

**************************************************************************** 


CHIP 

68030 




XDEF 

START,END1,INT HANDLER 



XDEF 

LOOP,SIMINT_CA,COUNTER 



SECTION 

INTR_DATA 



SIMINT CA 

DC . L 

0 

;Set up a memory location to 





; be the control address. 


COUNTER 

DC . L 

0 

;Set up a memory location that 





; the program writes to. 



ORG 

038H 

;TRAP #14 



DC . L 

INT HANDLER 

;Notice that the address of the 





/ interrupt handler routine is 





/ contained in the vector address 




; for a TRAP #14. 



SECTION 

INTR_PROG 



START 

MOVE.L 

#0,COUNTER 

;Clear the contents of the counter 1 




; address. 



MOVE.B 

#0FFH,SIMINT CA 

;Enable simulated interrupts. 



MOVE.L 

# OFFFFFFFH,DO 

;Set up a delay counter value. 


LOOP 

SUBQ. L 

# 1, DO 

;Delay for a while. 



BNE 

LOOP 




MOVE. B 

#0,SIMINT CA 

/Disable simulated interrupts now. 

END1 

BRA.B 

END1 

/Continuous loop. 


INT__HANDLER 



/This is the interrupt handler 





/ routine. 



ADDQ.L 

#1,COUNTER 

/Increment the contents of COUNTER. 


RTE 


/Return from exception. 



END START 

/Define the transfer address so 

that 




/ you may run or step from 
/ transfer__address. 






Figure 9-1. Simulated Interrupt Test Program 
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Simulated Interrupt 
Configuration 


While the emulation software may appear to be doing several 
things concurrently, for example; polling up to six simulated I/O 
control addresses, polling a simulated interrupt control address, 
and updating a display, it is in fact only a single HP-UX task 
performing each of these emulation tasks sequentially. This means 
that the simulated interrupt must complete before any of the other 
tasks can begin. That is a motivation for limiting the execution of a 
simulated interrupt handler to a very short period. 

If the handler is permitted to execute for an indefinite period of 
time, it is possible for the entire emulation program to be ’locked 
up’ by an interrupt handler that is waiting for an event that never 
occurs. 

The final difference between simulated interrupts and real 
interrupts is that it is not possible for a simulated interrupt to 
occur while a simulated interrupt is being handled or while the 
emulator is executing in the monitor. 


The simulated interrupt facility is not available in real time mode. 
If real time mode is enabled, the simulated interrupt configuration 
questions are not asked. When real-time mode is not enabled, the 
command line displays the following question: 

Modify simulated interrupt configuration? no (yes) 

Press Return for the default (no) response. 

Press yes Return to modify the simulated interrupt configuration. 

If you answer no the questions will be skipped. If you answer yes, 
the simulated interrupt questions will be asked. The simulated 
interrupt questions are: 

Enable polling for simulated interrupts? no (yes) 

no if no is selected, emulation does not poll a simulated 
interrupt control address and never causes a simulated 
interrupt to occur. 

yes if yes is entered, the configuration questions are asked: 
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Function code data space ? none (SUP_DATA) (USR_DATA) 

This question asks you to specify the data space where the 
simulated interrupt control address is located. 

If during memory configuration, you specified modify 
defined__codes none, you should use the default answer (none) here. 

If you specified modify defined_codes all, you should select 
SUP_DATA or USR_DATA as appropriate for your system. 

If you specified modify defined_codes prog_data, you should select 
USR_DATA. 

Simulated interrupt control address? SIMINT_CA (< Addr) 

Enter the value of the simulated control address in response to this 
question. The value may be a symbolic value or a numeric value. 
The default is the symbolic value SIMINT_CA. 

If you are not linking the emulation monitor program with your 
target system program, you must be careful when using a symbolic 
control address such as SIMINT_CA. 

The monitor program will store the location of the control address 
each time that it executes. If you modify your program, and then 
reload the program without loading the monitor, there is a chance 
that the symbolic control address will have changed. The monitor 
program will not recognize a change unless you reload it. 

If you do not reload the monitor each time that you load the target 
system program, you must ORG the control address to a specific 
location. If you ORG the address, make sure that you modify the 
"Simulated interrupt control address" configuration question to 
point to the new address. 

Another solution is to link the monitor program with your 
program. This causes the monitor to recognize any new address 
because it loads with your program. 

A similar consideration occurs if you modify the control address 
configuration question. If you are running your program, and then 
modify the configuration, you must reload your program (and the 
monitor). Otherwise, the system software does not recognize the 
new control address and may write to an unknown address. 
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Restrictions On 
Simulated Interrupts 


Maximum delay (in milliseconds) for simulated interrupt? 25 

(<NUMB>) 

The final simulated interrupt configuration question requests the 
time, in milliseconds, to allow a simulated interrupt handler to 
execute before assuming that execution of the handler has failed 
and generates a break to the monitor. 

The default time is 25 milliseconds. The default time is 
approximately equal to the time required to initiate a simulated 
interrupt and check for its completion on an HP 9000. Even 
though the resolution of this specification is one millisecond, 
because of the time that is required to check for completion, the 
effective resolution is approximately 15 milliseconds. For example, 
changing the maximum delay from 25 milliseconds to 26 
milliseconds probably has no effect on execution. Emulation does 
not always wait for the maximum delay to pass. If the interrupt 
handler completes any time before the maximum delay time, 
emulation forces an immediate return to the interrupted code. 

The input to this question is limited to the range of 1 through 
10000. Therefore, the maximum delay is 10 seconds. This upper 
limit was chosen to prevent ’locking up’ emulation by an interrupt 
handler that fails to terminate. 

If the user’s interrupt handler routine exceeds the maximum delay 
allowed, the following error message appears on the status line: 

"ERROR: Simulated interrupt failed to complete ”. 


Restrictions on the use of simulated interrupts are: 


a Simulated interrupts are not supported by the background 
monitor. 

H When using MMU, all simulated interrupt control 
addresses must be mapped 1:1. 

a When using MMU, the memory for simulated interrupts 
must always be accessible from the supervisor state of the 
processor. 
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Modifying The 
Monitor To Use 
Simulated 
interrupts 


The user defined simulated interrupt function allows you to 
implement interrupt driven code on an emulator which is out of 
circuit. This command will typically cause a branch to your 
interrupt handler by means of a TRAP instruction. This command 
must set the boolean variable SIM_INTS_ENABLED to TRUE 
and copy the control address to SIM_INT_CA so that the monitor 
can disable simulated interrupts on entry. If simulated interrupts 
are not disabled on entry to the monitor, the break softkey will not 
function. 

The monitor program must be modified before you can use the 
simulated interrupt feature. Find the following block of code 
shown in figure 9-2 in the monitor program. 

The TRAP #14 instruction will cause the interrupt routine to be 
serviced. You must uncomment the instruction or, if you wish to 
use a different instruction, you must provide the instruction in the 
same area of the monitor as the TRAP #14 instruction. If you use 
another TRAP or different instruction, you must be sure that the 
routine will be found by the monitor. For example, if you use the 
TRAP #14 instruction, you must make sure that the address 
information for your exception routine is in the vector table at 
address 038h. 

When you are finished editing the emulation monitor, be sure to 
save your changes. It will be necessary to re-assemble and relink 
the monitor in order to use the simulated interrupts feature. 
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COMMAND 9 


USER DEFINED SIMULATED INTERRUPT FUNCTION 


* THE USER DEFINED SIMULATED INTERRUPT FUNCTION ALLOWS THE USER TO 

* IMPLEMENT INTERRUPT DRIVEN CODE ON AN EMULATOR WHICH IS OUT OF 

* CIRCUIT. THIS COMMAND WILL TYPICALLY CAUSE A BRANCH TO THE USERS 

* INTERRUPT HANDLER VIA A TRAP INSTRUCTION. THIS COMMAND MUST SET 

* THE BOOLEAN SIM_INTS_ENABLED TO TRUE AND COPY THE CONTROL ADDRESS 

* TO SIM_INT_CA SO THE MONITOR CAN DISABLE SIMULATED INTERRUPTS ON 

* ENTRY. IF SIMULATED INTERRUPTS ARE NOT DISABLED ON ENTRY TO THE 

* MONITOR, THE break SOFTKEY WILL NOT WORK. 

* 

* THE 64000 WILL SET UP MONITOR CMDBUF; SCRADDR TO Simulated 

* interrupt control address ancT issue COMMAND 8009H. 

* 

* WHEN THE COMMAND IS COMPLETE, THE 64000 EXPECTS THE PROCESSOR 

* TO BE IN MONITOR. 

* 

SIM_INTERRUPT 

* A NON-ZERO VALUE INDICATES THAT SIMULATED INTERRUPTS ARE ENABLED 

MOVE. B #0FFH, SIM_INTS_ENABLED 

* STORE 0FFH AT SIM_INT_CONTENTS TO KEEP SIMULATED INTERRUPTS ENABLED 

MOVE.B #0FFH,SIM_INT_CONTENTS 

* STORE THE INTERRUPT CONTROL ADDRESS THAT WAS PASSED BY THE 64000 

MOVE.L SRC_ADDR,DO 

MOVE.L DO,SIM_INT_CA 

* INSTRUCTIONS TO BRANCH TO THE USERS INTERRUPT HANDLER GO HERE 

* THIS WILL TYPICALLY BE A TRAP INSTRUCTION. 


LOOP REENTRY 


Figure 9-2.Simulated Interrupt Function Code 



9-12 Simulated I/O & Interrupts 





10 



How The Emulator Works 


Overview 



This chapter describes how the following emulator functions work: 

■ The are_you_there monitor function. 

■ The run command. 

■ Software breakpoints. 

■ Single stepping with foreground monitor. 

■ Single stepping with background monitor. 

■ Target memory transfers. 

■ Displaying CPU registers. 

■ Modifying CPU registers. 
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Introduction The information provided in this chapter will give you a better 

understanding of how the emulator works and how the emulator 
interacts with your target system. This information, along with the 
information provided in chapter 6, Using the Emulator, should 
help you use the emulator more effectively and avoid problems that 
can occur when the emulator is used with a target system (in-circuit 
emulation mode). 


Note 



The algorithms described apply to both background and 
foreground monitors unless otherwise specified. 
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Are You There 
Function? 


The "are_you_there" monitor function is the means by which the 
host computer determines whether or not the 68030 CPU is 
executing the monitor at a particular time. It is used primarily to 
display the "running" and "running in monitor" status line messages. 

It also performs the important function of checking to see that a 
break request (level 7 interrupt) resulted in a successful entry to 
the monitor. The host computer issues break requests for all 
emulation functions requiring the use of the monitor. If the break 
fails, the host computer is unable to complete the user specified 
command, and displays a "cannot break into monitor" message. 

The following algorithm describes how the are_you_there function 
works. 

1. The host computer writes the value 8000h (bit 15 = 1) to 
the monitor data location MONITOR_CONTROL. 

2. If the emulation monitor is executing, and has completed a 
previous command, it executes an idle loop. In the idle 
loop, the monitor is waiting for a user command or for the 
host to make an "exit monitor" request. 

If the idle loop is executing and MONITOR_CONTROL is 
set to 8000h by the host, the monitor responds by clearing 
bit 15 (MONITOR_CONTROL = 0), and returning to the 
idle loop. 

If the 68030 CPU is executing in the user program, bit 15 
is not cleared, leaving MONITOR CONTROL set to 
8000h. 

3. The host computer reads monitor data location 
MONITOR_CONTROL. 

If bit 15 of MONITOR_CONTROL = 0, the monitor is executing. 

If bit 15 of MONITOR_CONTROL = 1, the user program is 
executing. 
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The Run 
Command 


Run From Command 


The run command starts execution of your user program. The 
command allows you to run from a specified address, run until a 
specified address is executed, or run from a start address until a 
specified address. The following algorithms describe how the run 
command is implemented. 

When you execute the command "run from 
{SUPERVISOR_STATE | USERSTATE} <address>", the 
following algorithm is executed. 

1. The host computer initiates a break to the monitor (level 7 
interrupt). 

2. The host verifies that the 68030 CPU is executing in the 
emulation monitor. If the monitor is not executing, the 
error message "cannot break into monitor" is displayed. 

3. The host modifies the monitor copy of the return address 
obtained on entry to the monitor from the level 7 
interrupt. It sets the return address to the value specified 
in the run command. 

4. The host modifies the monitor copy of the CPU status 
register obtained on entry to the monitor from the level 7 
interrupt. 

a. If the command specifies "SUPER VISORSTATE", 
the host sets the SUPERVISOR/USER bit to 1 
(supervisor) so that the 68030 CPU will execute in 
supervisor mode on exit from the monitor. 

b. If the command specifies "USER_STATE", the host 
sets the SUPERVISOR/USER bit to 0 (user) so that 
the 68030 CPU will execute in user mode on exit from 
the monitor. 

5. The host initiates a return (RTE) to the user program 
from the monitor by writing the "exit monitor" command 
(value 8001H) to monitor variable 

MONITOR CONTROL. 
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Run Until Command 


Run From ... Until 
Command 


6. The host verifies that the 68030 CPU has exited the 
monitor. If the emulator monitor is still executing, the 
error message "monitor did not respond to exit request" is 
displayed. 


When you execute the command "run until < address >", the 
following algorithm is executed. 

1. The host computer initiates a break to the monitor (level 7 
interrupt). 

2. The host verifies that the 68030 CPU is executing in the 
emulation monitor. If the monitor is not executing, the 
error message "cannot break into monitor" is displayed. 

3. The host computer reads the 16-bit word at < address > 
and saves it internally. 

4. The host insci is a BKPT instruction at < address >. The 
breakpoint is marked internally as a one-shot breakpoint. 

5. The host initiates a return (RTE) to the user program 
from the monitor by writing the "exit monitor" command 
(value 8001H) to MONITOR CONTROL. 

6. The host verifies that the 68030 CPU has exited the 
monitor. If the emulator monitor is still executing, the 
error message "monitor did not respond to exit request" is 
displayed. 


When you execute the command "run from 
{SUPERVISOR_STATE | USER_STATE} <addressl> until 
<address2>", the following algorithm is executed. 

1. The host computer initiates a break to the monitor (level 7 
interrupt). 

2. The host verifies that the 68030 CPU is executing in the 
emulation monitor. If the monitor is not executing, the 
error message "cannot break into monitor" is displayed. 
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3. The host computer reads the 16-bit word at <address2> 
and saves it internally. 

4. The host inserts a BKPT instruction at <address2>. The 
breakpoint is marked internally as a one-shot breakpoint. 

5. The host modifies the monitor copy of the return address 
obtained on entry to the monitor from the level 7 
interrupt. It sets the return address to the value 
<addressl> specified in the run command. 

6. The host modifies the monitor copy of the CPU status 
register obtained on entry to the monitor from the level 7 
interrupt. 

a. If the command specifies "SUPERVISOR_STATE", 
the host sets the SUPERVISOR/USER bit to 1 
(supervisor) so that the 68030 CPU will execute in 
supervisor mode on exit from the monitor. 

b. If the command specifies "USER_STATE",then the 
host sets the SUPERVISOR/USER bit to 0 (user) so 
that the 68030 CPU will execute in user mode on exit 
from the monitor. 

7. The host initiates a return (RTE) to the user program 
from the monitor by writing the "exit monitor" command 
(value 8001H) to MONITOR CONTROL. 

8. The host verifies that the 68030 CPU has exited the 
monitor. If the emulator monitor is still executing, the 
error message "monitor did not respond to exit request" is 
displayed. 




Software 

Breakpoints 


The following sections describe how the software breakpoint 
function is implemented in the 68030 emulator. Software 
breakpoints enable you to enter software breaks into your user 
program as an aid in debugging your user software. Software 
breakpoints are also used in the implementation of the run until 
command. 


Note 



When using the foreground monitor, the exception vector table is 
referenced only in the case of permanent breakpoints, which make 
use of the trace exception vector (VBR+24h). If one-shot 
breakpoints are working correctly, but permanent breakpoints fail, 
verify that the trace exception vector properly references the 
monitor (memory location MONITORJENTRY). 



Setting A Software 
Breakpoint 


When you execute the command "modify sw_breakpoint set 
{permanent | ones hot} <bkpt_addr>", the system executes the 
following algorithm. 


1. The host computer initiates a break to the monitor (level 7 
interrupt). 


2. The host computer detects that we actually got to the 
monitor, issuing an error message "cannot break into 
monitor" if not. 



3. The host gets the 16-bit word at <bkpt_addr> and saves it 
in ORIG_INST in host system memory. 

4. The host inserts the BKPT instruction at <bkpt_addr>. 

5. The host initiates a return (RTE) to the user program 
from the monitor. 

6. Host verifies that the emulation monitor was exited, and 
issues an error message if not. 
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Executing A Software When the 68030 CPU executes the BKPT instruction specified 
Breakpoint during emulation configuration, the following events occur: 

1. Emulation circuitry detects the occurrence of a BKPT 
instruction and responds by jamming into the emulation 
monitor at SWBKJENTRY. 


Note 


Only the BKPT instruction specified during emulator 
configuration is recognized by the emulator. 


2. The host detects that a breakpoint was executed and issues 
the message "breakpoint hit at address XXXX." 

3. The host restores the original instruction saved in 
ORIGJNST to <bkpt_addr>. 

4. The emulation monitor enters the idle loop, waiting for a 
user command. 


Executing A Run When you specify a run command after executing a software 
Command After breakpoint, the following events occur: 

Executing A Software 
Breakpoint 


"run” 

1. The host computer determines if the last BKPT instruction 
detected is permanent or one-shot. 

2. If the breakpoint is one-shot, the emulation monitor 
returns (RTE) to the user program to begin execution at 
address BKPT_ADDR. 

3. If the breakpoint is permanent, the 68030 CPU is 
instructed to single-step the instruction at BKPT_ADDR 
and return to the monitor. 
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4. The host computer reads the emulation monitor variable 
MONITOR_CONTROL to verify that the emulator is 
executing the emulation monitor. If the emulator is not 
executing in the monitor, the message "cannot break into 
monitor" is displayed and the run command is aborted. 

5. The host resets the breakpoint and returns (RTE) to the 
user program as described in steps 2 through 6 of the 
"Setting A Software Breakpoint" section. 

"run from ADDR" 


1. The host computer determines if the last BKPT instruction 
executed was permanent or one shot. 

2. If the breakpoint is oneshot, the emulation monitor 
returns* (RTE) to the user program and begins execution 
at address ADDR. 

3. If the breakpoint is permanent and the "run from" address 
is set equal to the breakpoint address BKPTADDR, the 
68030 CPU is instructed to single-step the instruction at 
BKPT_ADDR and return to the emulation monitor. 

4. The host resets the breakpoint as described in steps 2 
through 4 of the "Setting A Software Breakpoint" section 
and then returns* (RTE) to the user program. User 
program execution begins at ADDR. 

*The returns to the user program are accomplished by 
modifying the stack so that the RTE instruction in the 
monitor will return to address ADDR, rather than the 
address originally contained on the stack. 
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Single Stepping 
With Foreground 
Monitor 


The following algorithm describes how the single-stepping function 
is implemented in the forground monitor. The single-step function 
uses the trace exception vector in the exception vector table. If this 
vector (VBR + 24h) is set incorrectly, single stepping will fail. 


When the user executes a step command, the following events 
occur: 

1. The host computer initiates a break to the emulation 
monitor program by means of a level 7 interrupt. 

2. The host computer reads the emulation monitor variable 
MONITOR_CONTROLto verify that the emulator is 
executing the emulation monitor. If the emulator is not 
executing in the monitor, the message "cannot break into 
monitor" is displayed and the step command is aborted. 

3. The host instructs the monitor to set the trace bits in the 
68030 microprocessor status register (Tl = l, T0=0). This 
enables the 68030 trace function. 

4. If the user specified a "from < address >" the host sets the 
program counter value on the return stack to < address > 
so that, upon returning from the monitor to the user 
program, program execution will begin at < address >. 

5. The host initiates a return (RTE) to the user program 
from the monitor. 

6. The 68030 CPU executes a single instruction, and takes the 
trace exception which reenters the monitor at 
MONITOR_ENTRY. Note that the trace exception vector 
(VBR+24h) must reference MONITORJENTRY for this 
to function correctly. 

7. The host verifies that the emulator is executing in the 
monitor as described in step 2. 
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8. The host instructs the monitor to clear the trace bits in the 
68030 microprocessor status register (T1 = 0, TO = 0). 
This disables the 68030 trace function. 

9. The emulation monitor enters an idle loop, waiting for a 
user command. 


Single Stepping 
With Background 
Monitor 


The following algorithm describes how the single-stepping function 
is implemented in the background monitor. 


When the user executes a step command, the following events 
occur: 

1. The host computer initiates a break to the emulation 
monitor program by means of a level 7 interrupt. 

2. The host computer reads the emulation monitor variable 
MONITOR_CONTROL to verify that the emulator is 
executing the emulation monitor. If the emulator is not 
executing in the monitor, the message "cannot break into 
monitor" is displayed and the step command is aborted. 

3. The host puts the emulator in "single step" mode by setting 
a control bit (STEP) to 1. 

4. If the user specified a "from <address>” the host sets the 
program counter value on the return stack to < address > 
so that, upon returning from the monitor to the user 
program, program execution will begin at < address >. 

5. The host initiates a return (RTE) to the user program 
from the monitor. 
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6. The STEP bit, being set to 1, initiates a BREAK action 
after one instruction has been executed. This forces the 
CPU to reenter the monitor at MONITOR_ENTRY. 

7. The host verifies that the emulator is executing in the 
monitor as described in step 2. 

8. The emulation monitor enters an idle loop, waiting for a 
user command. 


Target Memory 
Transfers 


The following section describes the two modes the emulator uses 
to transfer data to and from target memory. In the automatic mode, 
the emulation monitor always attempts to longword align the 
transfer. Due to the dynamic bus sizing facility of the 68030, this 
alignment improves total transfer time with 8 and 16-bit memory 
systems, but is most effective with 32-bit memory systems. This 
algorithm can be tuned to meet specific target system requirements. 

Alternately, the display/modidy command can be issued so that all 
transfers can be made in a "byte”, "word”, or "longword" mode. 

The "auto" mode is described below: 

1. At the beginning of the transfer, the monitor examines the 
lower two bits of the initial target system address to be 
read from or written to. 

a. If bit 0 of this address is 1, the monitor transfers a 
single byte to or from the target system using a 
MOVES.B instruction. Following this, the target 
system address is incremented by one to reflect the 
next address to be transferred. 

b. If bit 0 of the initial target system address is 0, the byte 
transfer and address increment does not occur. 

This first step causes the target system address to be 
aligned to a word address, where bit 0 of the address is 0. 
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2. The monitor examines bit 1 of the target system address. 

a. If bit 1 of this address is 1, the monitor transfers a 
single word to or from the target system using a 
MOVES.W instruction. Then, the target system address 
is incremented by two to reflect the next address to be 
transferred. 

b. If bit 1 of the initial target system address is 0, the word 
transfer and address increment does not occur. 

This step aligns the target system address to a longword 
address, where bits 1 and 0 of the address are 0. 


3. The target system address is now longword aligned; that is, 
address bits 1 and 0 are both 0. The bulk of the transfer is 
then carried out using longword transfers. The operation 
of the transfer up to this point is summarized in figure 10-1 


Starting Addr 

Transfer Description 

Eita 1 and Q 


1 1 

a. Copy a byte to longword align 

b. Increment target address by 1 

c. Copy a longword 

d. Increment target address by 4 

e. Repeat steps H c" and "d" 

1 0 

a. Copy a word to longword align 

b. Increment target address by 2 

c. Copy a longword 

d. Increment target address by 4 

e. Repeat steps "c" and "d" 

0 1 

a. Copy a byte to word align 

b. Increment target address by 1 

c. Copy a word to longword align 

d. Increment target address by 2 

e. Copy a longword 

f. Increment target address by 4 

g. Repeat steps "e" and "f" 

0 0 

a. Copy a longword 

b. Increment target address by 4 

c. Repeat steps "a" and "b" 


Figure 10-1. Target Memory Transers in Automatic Mode 
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4. After each longword transfer, the monitor examines the 
number of bytes remaining in the transfer. If the number is 
0, the transfer is complete, and the monitor returns to the 
idle loop. If the number of bytes remaining to be copied is 
less than 4 prior to a longword transfer, longword transfers 
are no longer used, and control passes to monitor code 
that finishes up the remaining bytes (3, 2 or 1) of the 
transaction. 

a. If 3 bytes remain, a word transfer followed by a byte 
transfer is executed. 

b. If 2 bytes remain, a single word transfer is performed. 

c. If a single byte remains, a byte transfer is used. This 
monitor function is summarized in figure 10-2. 


Number of Ryfes Remaining 


Transfer Description 


4 

a. 

Copy a longword 



b. 

Increment target address by 

4 


c. 

Return to monitor idle loop 


3 

a. 

Copy a word 



b. 

Increment target address by 

2 


c. 

Copy a byte 



d. 

Increment target address by 

1 


e. 

Return to monitor idle loop 


2 

a. 

Copy a word 



b. 

Increment target address by 

2 


c. 

Return to monitor idle loop 


1 

a. 

Copy a byte 



b. 

Increment target address by 

1 


c. 

Return to monitor idle loop 


0 

a. 

Return to monitor idle loop 



Figure 10-2. Monitor Operation At End Of Transfer 
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Displaying Target When you execute a display memory command with an address 
Memory range mapped to target system memory, the emulation monitor 

reads the specified areas of target memory and copies the memory 
locations to an internal monitor buffer for transfer to the host 
computer. This process is described in the following steps: 

1. The host computer initiates a break to the monitor (level 7 
interrupt). 

2. The emulation monitor enters the idle loop, waiting for a 
host command. The idle loop is located at monitor 
program symbol MONITOR_LOOP. 

3. The host computer detects that the 68030 CPU is 
executing in the emulation monitor. If the CPU is not 
executing in the monitor, the host issues the error message 
"cannot break into monitor". 

4. The host computer writes the memory transfer parameters 
to designated monitor locations listed as follows: 


Description Monitor 

Location 

a. Number of bytes to read.. . . . .PARM1 

b. Starting address of target system read...PARM2 

c. Function codes for target system read.PARM3 

d. Starting address of monitor data buffer write.PARM4 

e. Function codes for monitor data buffer write.PARM5 

f. Access mode . PARM6 


The monitor data buffer begins at monitor data symbol 
MON_XFR_BUF and is always referenced with the 
CPU_SPACE function code for the foreground monitor. 

5. The host writes the "read user memory” command (8003H) 
to MONITOR_CONTROL. This causes the monitor to 
exit the idle loop and begin execution at monitor program 
symbol COPY. 
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6. The monitor sets up the transfer according to the six 
parameters listed above, and begins to copy target system 
memory values to the monitor data buffer using the 
algorithm described in the previous section. See the 
emulation monitor listing for additional details. Look at 
the monitor code following monitor program symbol 
COPY. 

7. The host computer detects that the transfer has completed 
by observing a value of 0000H in MONITOR_CONTROL. 
The host then reads and displays the information in the 
monitor data buffer. If the display memory command 
requested a display of more data bytes than the monitor 
transfer buffer can hold, the host computer sets up a new 
transfer for the remaining information by repeating the 
steps beginning with step 4. 

8. The host computer initiates a return (RTE) to the user 
program from the monitor. This occurs as a result of the 
host writing the "exit monitor" command (8001H) to 
MONITOR_CONTROL This operation does not occur if 
the display memory command was issued while executing 
in the emulation monitor. 


Copying from Target 
System Memory 


The algorithm for copying data from target memory is identical to 
that used when displaying target memory. 


Modifying Target When you execute a modify memory command with an address 

Memory mapped to target system memory, the emulation monitor writes to 
the specified areas of target memory, copying data from the 
emulation monitor data buffer. The data in the emulation monitor 
buffer is put there by the host computer. The process for modifying 
target memory is described in the following steps: 

1. The host computer initiates a break to the emulation 
monitor (a level 7 interrupt). 

2. The monitor enters the idle loop, waiting for a command 
from the host computer. The idle loop is located at 
monitor program symbol MONITOR_LOOP. 
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3. The host computer detects that the 68030 CPU is 
executing in the emulation monitor. If the CPU is not 
executing in the monitor, the host issues the error message 

"cannot break into monitor". 

4. The host writes the memory transfer parameters to the 
designated monitor PARM1 through PARM6. 

5. The host writes the "write user memory" command 
(8004H) to MONITOR_CONTROL. This causes the 
monitor to exit the idle loop and begin execution at 
monitor program symbol COPY. 

6. The monitor sets up the transfer according to the six 
parameters listed above, and begins to copy monitor data 
buffer values to the target system memory using the target 
memory transfer algorithm described previously. See the 
emulation monitor listing for additional details. Look at 
the monitor code following monitor program symbol 
COPY. 

7. the host determines that the transfer has completed by 
observing a value of 0000H in MONITOR_CONTROL. If 
the modify memory command requested a modify of more 
data bytes than could be held by the monitor transfer 
buffer, the host sets up a new transfer for the remaining 
information by repeating the steps beginning with step 4. 

8. The host initiates a return (RTE) to the user program 
from the monitor. This results from the host writing the 
"exit monitor" command (8001H) to 
MONITOR_CONTROL. This operation does not occur if 
the modify memory command was issued while executing 
in the emulation monitor. 


Copying to Target 
System Memory 


The algorithm for copying data to target system memory is 
identical to that used when modifying target memory. 
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Displaying The 
CPU Registers 


When you execute a display registers cpu command, the following 
algorithm is executed: 

1. The host computer initiates a break to the monitor (a level 
7 interrupt). 

2. The emulation monitor enters the idle loop, waiting for a 
command from the host computer. The idle loop is located 
at monitor program symbol MONITORJLOOP. 

3. The host detects that the 68030 CPU is executing in the 
emulation monitor. If the CPU is not executing in the 
monitor, the host issues the error message "cannot break 
into monitor". The "are_you_there?" function is used to 
determine whether or not the monitor is executing. 

4. The host reads and displays the register image save area 
that was constructed on entry into the monitor (i.e. the 
monitor data area starting with symbol PCH and ending 
with DFCT). 

5. The host initiates a return (RTE) to the user program 
from the emulation monitor. This results from the host 
writing the "exit monitor" command (8001H) to 
MONITOR_CONTROL This operation does not occur if 
the display registers cpu command was issued while 
executing in the emulation monitor. 
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Modifying The 
CPU Registers 


When you execute a modify registers cpu <regname> to < value > 
command, the following algorithm is executed: 

1. The host computer initiates a break to the emulation 
monitor (a level 7 interrupt). 

2. The monitor enters the idle loop, waiting for a command 
from the host computer. The idle loop is located at 
monitor program symbol MONITOR_LOOP. 

3. The host detects that the 68030 CPU is executing in the 
monitor. If the CPU is not executing in the emulation 
monitor, the host issues the error message "cannot break 
into monitor". The "are_you _there?" function is used to 
determine whether or not the emulation monitor is 
executing. 

4. The host writes the modified register value to the 
corresponding location in the register image save area 
constructed on entry to the monitor (i.e. the monitor data 
area starting with symbol PCH and ending with DFCT). 

5. The host initiates a return (RTE) to the user program 
from the emulation monitor. This results from the host 
writing the "exit monitor" command (8001H) to 
MONITOR_CONTROL. This operation does not occur if 
the modify registers cpu command was issued while the 
CPU was executing in the monitor. 

6. When exiting the monitor, the register image save area is 
read to reload all CPU registers with their original values 
on initial entry to the monitor (see monitor program 
symbol RTN3). Since the modify registers command 
changes values in the register image save area, these new 
values are loaded in the CPU registers on exit from the 
monitor. 
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Emulation Error Messages 


68030 Emulation 
Error Messages 


This appendix contains a list of 68030 emulation error messages 
with descriptions of the error and information on how to correct 
the error, when appropriate. This list describes the most serious 
emulation errors that you may encounter. 

Messages are listed in alphabetical order. 


Attempt to read 
guarded memory, 
addr= XXXX 


This message appears when an attempt is made to display a 
memory location mapped as "guarded" via the "display memory" 
command. The offending address is displayed in the XXXX field. 


Attempt to write 
guarded memory, 
addr = XXXX 


This message appears when an attempt is made to modify a 
memory location mapped as "guarded" via the "modify memory" 
command. The offending address is displayed in the XXXX field. 


Cannot break into This message is displayed when the host expects to find the CPU 
monitor executing the monitor, but the "are_you_there?" function indicates 
otherwise. This message occurs after issuing a command that 
normally causes a break to the monitor. 

If SUPERVISOR J>ROG and SUPERVISOR^)ATA areas are 
not overlayed for the emulation monitor, the "are_you_there?" 
function cannot function properly, resulting in this error message. 
If function codes are not in use, mapping overlays are not required. 

To determine the cause of the failure, setup an analysis trace to 
trigger on the acknowledge cycle for the level 7 interrupt: 

trace trigger_on a= Offffffffh s= fcode CPU_SPACE 
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If the analyzer does not trigger, then it is likely that no level 7 
interrupt was generated by the emulator. Check that the "Enable 
emulator use of INT7?" configuration question has been answered 
"yes". If so, a hardware error has occurred or the CPU is in a Reset, 
halt or DMA state (in which case the CPU will not respond to the 
level 7 interrupt in a timely manner. 

The tracelist should show an emulator generated jam cycle. 
MONITOR_ENTRY should be the address supplied by these 
cycles. Compare the tracelist of the monitor entry point to a 
monitor listing. Determine that the monitor has not been 
inadvertently overwritten. Be sure that the monitor area is 
overlayed with SUPERVISORJDATA and 
SUPERVISORJPROGRAM space (not necessary if function 
codes are turned off). 

Check to see that the monitor enters, and stays in the monitor idle 
loop. If interrupts are enabled in the monitor, an external interrupt 
routine may be exiting the monitor and not returning properly. Or, 
if there are frequent interrupts being processed, the 
"are_you_there?" function may be simply timing out. 

Next, setup the analyzer to trigger on the "are_you_there?" monitor 
command: 

trace trigger_on a= MONITOR CONTROL 
d= 8000xxxxH s= access READ 

The address and data specifications may differ, depending on the 
address of MONITOR_CONTROL, and the width of the memory 
system being referenced. 

Determine that the "are_you_there?" function in the monitor 
(ARE_THERE) is functioning properly by observing the trace 
after capturing the condition where MONITOR__CONTROL is 
read as 8000H. Compare this trace to the monitor listing. 


Could not disable 
breakpoint at 
address XXXX 


This message normally results from attempting to clear a 
breakpoint in target system memory, but for some reason, the 
emulator could not break into the monitor in order to clear the 
breakpoint. 
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Could not enable 
breakpoint at 
address XXXX 


monitor did not 
respond to exit 
request 


This message normally results from attempting to set a breakpoint 
in target system memory, but for some reason, the emulator could 
not break into the monitor in order to set the breakpoint. This 
message also occurs when attempting to set a breakpoint in target 
ROM, but does not occur when setting a breakpoint in emulation 
RAM or ROM. Trying to set a breakpoint in a guarded area of 
memory will also result in this error message. 

This message is displayed when the host expects to find the CPU 
executing somewhere other than in the monitor, but the 
"are_you_there" monitor function indicates otherwise. This 
message occurs after issuing a command that results in a return to 
the user program from the monitor (i.e. display registers while the 
user program is executing, or "run” while in the monitor, etc.). 

If SUPERVISOR_PROG and SUPER VISOR_DATA areas are 
not overlayed for the emulation monitor, the "are_you_there?” 
function cannot function properly, resulting in this error message. 
If function codes are not in use, mapping overlays are not required. 

To determine the cause of the failure, setup an analysis trace to 
trigger on the "exit monitor" command. This can be done with the 
following trace specification: 

trace trigger_on a= MONITORCONTROL 
d= SOOlxxxxH s= access READ 

Note that the address and data specifications may differ, depending 
on the address of MONITOR_CONTROL, and the width of the 
memory system being referenced. 

If the monitor is not executing (i.e. in an interrupt routine or 
elsewhere) at the time of an "exit monitor” command, the 
command cannot be recognized and this error message will result 
after a timeout. 

Observe the exit mechanism from the monitor, and compare the 
acquired trace to the monitor listing. Be certain that the monitor 
has not been overwritten inadvertently. 

Once the monitor is exited, check that the user program executes 
properly. If the user program returns to the monitor immediately 
after the "exit monitor" command is issued, this message appears. 
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No breakpoint exists 
at address XXXX 


This message is emitted if the user attempts to clear a breakpoint 
at an address for which no breakpoint was previously specified. The 
emulation system is only aware of breakpoints set by the "modify 
sw_breakpoints set..." command. If a "modify memory..." 
command was used to set the breakpoint, or if the breakpoint 
existed in the absolute code loaded into the emulator, it is not 
possible to clear such breakpoints using "modify sw_breakpoints 
clear..." commands. 




(no termination) 
message in tracelist 


This message normally indicates that a particular CPU cycle was 
terminated by LBERR or LHALT instead of the usual termination 
by DSACKs or STERM. 


no memory cycles 


This message can also be a clue that the target system is violating 
the MC68030 specification which specifies that the DSACK signals 
must not be negated before address strobe is negated by the CPU. 
This is the case because the analyzer uses a derivative of address 
strobe as an analysis clock. If DSACKs are high prior to the 
low-to-high transition of address strobe, a "no DSACK" message 
can result. 

This status line message indicates that the emulator has not 
received a low-to-high or high-to-low transition on address strobe 
for at least 25-30 ms. This message most often appears when 
executing from cache, if there are no external cycles for long 
periods of time. 


Any device that drives address strobe will inhibit the message, 
including the emulator 68030, DMA devices, and coprocessors. If a 
DMA mechanism, for example does not drive address strobe, this 
message may appear after the specified timeout. (Note that bus 
cycles where address strobe is not driven cannot be captured by the 
analyzer.) 

This message is simply a warning that address strobes are 
infrequent. 


Reset (with capital 

"R") 


This message indicates that the CPU is being reset due to the use 
of the reset softkey in the emulation software. 
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reset (with lower case 
"r") 

running 

running in monitor 

slow dev at a= XXXX 
(YY) 


This message indicates that the CPU is being reset by target system 

hardware. 


This message indicates the emulator is running in a user program. 


This message indicates the emulator is running in the monitor. 


This status line message indicates that the CPU is presently 
attempting to run a bus cycle, but the cycle has not completed after 
approximately 25 ms. This means that although the CPU asserted 
address strobe (set it low), the addressed memory (I/O device, etc.) 
has not yet returned DSACKs, STERM, BERR, and/or HALT as 
appropriate. 

The XXXX field above indicates the address of the attempted 
cycle, and the YY field indicates the function code applied to the 
cycle according to the following table: 

SD = Supervisor Data 
SP = Supervisor Program 
UD = User Data 
UP = User Program 
RO = Reserved Address Space 0 
R3 = Reserved Address Space 3 
R4 = Reserved Address Space 4 
CS = CPU Space 

Note that this message is simply a warning that the current cycle is 
taking an unusually long time to complete. 
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Source Files For Getting Started Examples 


Introduction This appendix contains the listings of the "towers.c" and "simint.c" 

source files. These two source files were compiled and linked with 
the emulation monitor program to form the towers.X absolute file 
which was used in all the examples in this manual that show the 
internal analyzer making trace measurements. The towers.c source 
listing is first in this appendix. The simint.c source listing is last. 
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Source File For 
towers.c 


/* LSD:§(#) 0.06 88/06/16 
/* @(mktid) (02.10 24Jun88) 

/* */ 

/* This program demonstrates the solution to the popular */ 

/* "Towers of Hanoi" brain teaser puzzle. The puzzle consists */ 
/* of 3 pegs and a number of discs of different diameters which */ 
/* fit over the pegs. The discs are ordered by their diameter, */ 
/* largest on the bottom, on one peg. The object is to move */ 
/* all of the discs from one peg to another such that they end */ 
/* up in the same order on the new peg using the minimum number */ 
/* of moves. Only one disc can be moved at a time, and a larger */ 
/* disc may never be placed on top of a smaller disc. */ 

/* */ 

/* The solution can be visualized using "display simulated_io" */ 
/* command. The number of discs is selected by responding to */ 
/* the input request using the "modify keyboard_to_simio" */ 

/* command and entering a number between 1 and 7. Multiple */ 

/* numbers separated by spaces can be entered before hitting */ 

/* return to get multiple executions of the program, and "C" */ 

/* may be entered to run the program continuously. */ 

/* */ 

/* The speed of the program can be modified in real time with */ 
/* the variable loc delay and the "modify memory" command. */ 

/* */ 

I* NOTE: This file has been designed with the use of "ifdef" */ 

/* to allow it to be compiled and run on the host as well as */ 

/* cross compiled for the emulator. */ 

/* If not the AxLS 68030 C compiler, then probably not an ANSI */ 
/* compiler so we must remove the const and void keywords. */ 

fifndef _m68030 

♦define const 
♦define void char 

♦endif 

♦include <stdio.h> 

♦include <stdlib.h> 

♦define TRUE 1 
♦define FALSE 0 
♦define NOVALIDENTRY 1 
♦define STDOUT 1 
♦define FIRSTCOL 0 
♦define LEFT 0 
♦define MIDDLE 1 
♦define RIGHT 2 

♦define MAX_DISC 7 
♦define MAX_CHARS 16 
♦define MAX_TOWERS 3 
♦define REPEAT 99 
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typedef struct { 

char disc_char[MAX_CHARS]; 
> DISC; 

typedef DISC TOWER[MAX_DISC]; 



static int run_continuous; 

static int num__discs = 4; /* we will use 4 discs as the default */ 

static int move_num; 

static int f ree__level [MAX_TOWERS ] ; 

static int disc_level[MAX_DISC]; 

static TOWER display[MAXJTOWERS]; 


/* This variable may be modified during emulation to change */ 
/* the speed of the program. */ 
const int loc_delay = 500; 


static DISC blank__disc = 

i t • t 


I'.'l'r' 




static TOWER disc_word = { 

\ t t r r t t f 

{ i i I i t i I / / i * o / » o / 

# / t t t r / 

{' # r # 

{' '•,• ','4','4','4','4', 

{' ', ' 6 ',' 6 ' , ' 6 ',' 6 ' / ' 6 ', ' 6 ' , 




# # >/ 

' ')/ 

# ')/ 
' 

# 7 ' > 



/* Enabling an analysis trace on activity within a function */ 
/* may not perform properly if the processor prefetches */ 
/* the function return (RTS) due to a previous branch. */ 
/* The AxLS C Compiler provides a debug */ 
/* capability that adds NOP instructions to prevent this */ 
/* condition (default options, or -OG should be used). */ 
/* */ 
/* A less desirable alternative would be to modify the */ 
/* source using a dummy statement to provide the padding. */ 
/* As an example, a write to the variable "rts_prefetch" */ 
/* just before the function return could be used. *f 
/* Because the prefetch can be up to 3 words long, we want */ 
/* the access address mode to be absolute long and will org */ 
/* it outside of base page, thus forcing a 3 word opcode. */ 


/* We will put it at the upper end of the monitor data block.*/ 


#ifdef m68030 


#ifndef DEBUGG 

#pragma SECTION DATA=0x20ff0 
int rts_prefetch; 
#pragma SECTION UNDO 
#endif 



#else 

int rts_prefetch; 

#endif 


/* externals */ 

lifdef INTERRUPTS 

tpragma SECTION PROG=simint 
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extern void enable_int(); 
extern void disable_int(); 
extern int sim__ints_serviced; 
extern int sim_int_ca; 

♦pragma SECTION UNDO 
♦endif 

/* for local forward referencing */ 

static void pause(); 

static void show_discs(); 

static void init_display(); 

static void towers(); 

static int ask_for_number(); 

main() 

{ 

♦ifdef INTERRUPTS 

enable__int (); 

♦endif 


run_continuous = FALSE; 


♦ifdef 

♦endif 


while ( ask_for_number(&num_discs) == TRUE ) 
_m68030 

clear_screen(STDOUT); 

move_num - 0; 
init_display(LEFT); 
show__discs ( ); 
pause(); 


{ 


towers(num_discs,LEFT,RIGHT,MIDDLE); 
show__discs (); 


/* ANSI supports concatenated strings, AxLS simio has cursor control */ 
♦ifdef m68030 


♦else 


♦endif 


pos_cursor(STDOUT, FIRSTCOL, num_discs+5); 
printf("\t\tPuzzle with %d discs can be solved in " 
"%d moves. \n",num_discs,move_num); 

printf("\n\t\tPuzzle with %d discs can", num_discs); 
printf(" be solved in %d moves. \n", move_num); 


pause(); 
pause(); 


return(0); 

> 

/****♦ Towers routines ***♦*/ 

static int ask_for_number(num) 
int *num; 

{ 

char err_char1,err_char2; 
int last__num, ret^val; 

last_num = *num; 
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if ( run_continuous == FALSE ) { 

#ifdef _m68030 

clear screen(STDOUT); 

print?("\n\nExecute 'modify keyboard_to_simio' then enter" 

" one of the followings" 

"\n\tNumber of discs to use [l-%d]" 

"\n\t'0' to exit program" 

"\n\t'C' to run continuously using last number entered\n\n" 
,MAX_DISC); 

#else 

printf("\n\nEnter one of the following:"); 

printf("\n\tNumber of discs to use [l-%d]",MAX_DISC); 

printf("\n\t'0' to exit program"); 

printf("\n\t # C' to run continuously using last number entered\n\n"); 

#endif 

while ( NOVALIDENTRY ) { 


*/ 


MAX_DISC) ) 
number!"); 


*/ 

*/ 

*/ 

*/ 


== ' 1 ') ) 


printf("?"); 

/* scanf will return one of the following three values: */ 
/* 1) "0" indicates a scanning error */ 
/* 2) "1" indicates valid input */ 
/* 3) "EOF" */ 


ret_val = scanf (" %d" , num) ; 

switch (ret_val) { 
case 0: 

err_charl = getchar(); 
err__char2 = getchar(); 

/* If a "C" is entered, the last number will be 
/* used forever (if it was valid). */ 

if (err_charl == 'C' ) { 

if ( (last_num < 1) || (last_num > 

puts(" invalid repeat 

else { 

*num = last_num; 
run_continuous = TRUE; 
return(TRUE); 

> 

> 

/* If the user hits the "suspend" softkey, as a 
/* courtesy the emulator sends an escape 1 
/* character sequence allowing the program to 
/* detect that the input was suspended, 
else if ( (err__charl == '\033') && (err__char2 
puts(" input suspended!"); 
else puts(" input error, re-enter line!"); 
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fflush(stdin); 

/* try again1 */ 
break; 


number1\n",*num); 


case 1: 

if (*num == 0) { 

printf(" exiting!\n"); 
return(FALSE); 

else if ((*num < 0) || (*num > MAX_DISC)) 

printf(” %d is not a valid 

/* try again1 */ 

else 

return(TRUE); 

break; 


case EOF: 

return(FALSE); 
break; 


> /* end switch ret_val */ 
> /* while no valid entry */ 


> /* if not run continuous */ 
return(TRUE); 

> 

static void pause() 

{ 

int i,j; 

for (i = 0;i < loc_delay; i++) 

for (j = 0; j < locdelay; j++) { 

> 


#ifndef DEBUGG 

rts_prefetch = 0; 

#endif 

> 

static void show_discs() 

{ 

DISC *disc__ptr; 
char *string, *p; 
int disc, tower, ch; 

if ( (p = string = (char *) malloc(BUFSIZ) ) == NULL ) { 
fputs("malloc failed\n",stderr); 
exit(1); 

> 

#ifdef _m68030 

pos_cursor(STDOUT, FIRSTCOL, 1); 

#endif 

for (disc = 0; disc < num_discs; disc++) { 

for (tower = 0; tower < MAX_TOWERS; tower++) { 

*p++ = '\t'; 

disc_ptr = &display[tower][disc]; 
for (ch = 0; ch < MAX_CHARS; ch++) 
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*p++ = disc_ptr-disc_char[ch]; 

> 

*p++ = '\n'; 

> 

fwrite(string,1,(int)(p-string), stdout); 


free(string); 

#ifdef ^11168030 

~Tf (move_num == 0) 

printf ( " \t-\t-\t--" 

’’\n\t Peg 0 \t Peg 1 \t Peg 2\n" 

"\n\t\tSolution for Towers with %d discs.\n”,num_discs); 

#else 

printf ( " \t-\t-\t-\n" ) ; 

printf("\t Peg 0 \t Peg 1 \t Peg 2\n"); 

if (move_num == 0) 

printf("\n\t\tSolution for Towers with %d discs.\n\n’’, 
num_discs); 

#endif 

> 

static void remove disc(disc, from__peg) 
register int disc,?rom_peg; 

{ 

disc—; 

display[from_peg][disc_level[disc]] = blank_disc; 
free_level[from_peg] = disc_level[disc]; 

> 

static void place_disc(disc,on_peg) 
register int disc,on_peg; 

{ 

disc—; 

display[on_peg][free_level[on_peg]] = disc_word[disc]; 
disc_level[disc] = free_level[on_peg]; 
free_level[on_peg]—; 

} 


static void move_disc(i,from,to) 
int i,from,to; 

{ 

move_jium++; 
show__discs ( ); 

printf("\n\n\n\n\t\tMove #%d: Move disk %d from peg %d to ",move_num,i,from); 
printf (’’peg %d \n",to); 


#ifdef 


#endif 


INTERRUPTS 

if ( sim_int_ca == -1 ) 

printf (’’\t\t%d simulated interrupts have been serviced. \n” 
,sim ints serviced); 


else 


printf("\t\tSimulated interrupts have been disabled. 


\n” ) ; 


remove_disc(i,from); 
place__disc ( i, to) ; 
pause(); 
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#ifndef DEBUGG 

rts_prefetch = 0; 

♦endif 

> 

static void init__display (start_tower) 
int start_tower; 

{ 

int tower,disc; 

/* initialize the display array to be blank */ 

for (tower = 0; tower < MAX_TOWERS; tower++) { 
for (disc = 0; disc < MAX_DISC; disc++) 

display[tower][disc] = blank_disc; 
free_level[tower] = num_discs - 1; 

> 

/* place num__discs on the specified tower */ 
for (disc = 0; disc < num_discs; disc++) { 

display[start__tower] [disc] = disc_word[disc]; 
disc_level[disc] = disc; 

} 

free_level[start_tower] = 0; 

> 

static void towers(n,from_peg,to_peg,aux_peg) 
register int n,from_peg,to_peg,aux_peg; 

{ 

if (n == 1) 

move_disc(1,from_peg,to_peg); 

else { 

towers(n-1,from_peg,aux_peg,to_peg); 
move_disc(n,from_peg,to_peg); 
towers(n-1,aux_peg,to_peg,frompeg); 

> 

} 
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Source File For 

simint.c 


/* LSD:@(#) . 

/* @ (mktid) . .... 

/* */ 

/* This file contains some very simple examples of routines to */ 

/* use with the simulated interrupt mechanism of the emulator. */ 

/* - */ 

/* If not the AxLS 68030 C compiler, then probably not an ANSI */ 

/* compiler so we must remove the const and void keywords. */ 

#ifdef _m68030 

#pragma SECTION PROG=simint DATA=data CONST=simint 
#else 

#define volatile 
#define void char 
#endif 

/* This variable records the number of serviced simulated interrupts. */ 
int sim_ints_serviced = 0; 


/* This variable will be used to control simulated interrupts and is */ 
/* specified in the emulator configuration file. The host and the */ 
/* monitor watch this "control address" to decide whether to perform */ 


/* the interrupt function or not. Simulated interrupts will be */ 
/* enabled when the control address flag is set to -1 and disabled */ 
/* if it is set to 0. The "modify memory" command can be used to */ 
/* enable and disable interrupts in real time once the program has */ 
/* has been started. */ 


/* Remember that using the "volatile" keyword restricts the compiler's */ 
/* optimization for the entire file, but guarantees proper access of */ 
/* variable. */ 

volatile int sim_int_ca = -1; 

void enable__int ( ) 

{ 

/* enable simulated interrupts from emulator */ 
sim__int_ca = -1; 

> 

void disable__int ( ) 

{ 

/* disable simulated interrupts from emulator */ 
sim__int__ca = 0; 

> 

#ifdef _m68030 

#pragma INTERRUPT 

static void sim_int_handler() 

{ 

/* service simulated interrupts from emulator */ 
sim_ints_serviced++; 
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> 


/* Initialize the interrupt vector table to point to our routine. */ 

♦pragma SECTION DATA=0xb8 

void (*trapl4)() = sim_int_handler; 

♦pragma SECTION UNDO 
♦endif 


B-10 Demonstration File Sources 



c 


Timing Comparisons 


Introduction This appendix contains tables which list: 

■ Timing comparisons between the MC68030 and the HP 
64430 emulator. 

■ DC electrical specifications for the HP 64430. 
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MC68030/HP 64430 Timing Comparisons 


13.5 AC ELECTRICAL SPECIFICATIONS - CLOCK INPUT 


Nu in 

Characteristic 

33.33 MHz 15 

HP 64430 

Unit 

Min 

Max 

Min 

Max 


Frequency of Operation 

20 

33 

20 

33 

Mhz 

1 

Cycle Time 

30 

80 

30 

80 

ns 

2,3 

Clock Pulse Width 

14 

66 

14 

66 

ns 

4,5 

Rise and Fall Times 

— 

3 

— 

3 

ns 


MC68030 electrical specifications reprinted courtesy Motorola, Inc. 


13.6 AC ELECTRICAL SPECIFICATIONS - READ AND WRITE CYCLES 


(Vcc = 5.0 Vdc +/- 5%; GND = 0 Vdc; T A = 0° to 70° C) 




33.33 MHz 15 

HP 64430 


Num 

Characteristic 

Min 

Max 

Min 

Max 

Unit 

6 

Clock High to FC, Size, RMC, CIOUT Address Valid 

0 

14 

0 

14 

ns 


Clock High to IPEND Valid 

0 

14 

0 

24 

ns 

6A 

Clock High to ECS, OCS Asserted 

0 

12 

0 

15 

ns 

6B 

FC, Size, RMC, CIOUT Address Valid to Negating 

ECS 

3 

— 

3 

... 

ns 


IPEND Valid to Negating ECS 

3 

— 

-1 

... 

ns 

7 

Clock High to FC, Size, RMC, CIOUT, Address, Data 
High Impedance 

0 

30 

0 

30 

ns 
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13.6 AC ELECTRICAL SPECIFICATIONS - READ AND WRITE CYCLES (Cont’d) 


(Vcc =5.0 Vdc +/- 5%; GND = 0 Vdc; TA = 0° to 70° C) 




33.33 MHz 15 

HP 64430 


Num 

Characteristic 

Min 

Max 

Min 

Max 

Unit 

8 

Clock High to FC, Size, RMC, IPEND, CIOUT, 

Address Invalid 

0 

— 

0 

... 

ns 

9 

Clock Low to AS, DS, CBREQ Asserted 

2 

10 

2 

15 

ns 

9A 1 

AS to DS Assertion Skew (Read) 

-8 

8 

-8 

8 

ns 

9B 14 

AS Asserted to DS Asserted (Write) 

22 

--- 

22 

— 

ns 

10 

ECS Width Asserted 

8 

--- 

7 

... 

ns 

10 A 

OCS Width Asserted 

8 

... 

7 

... 

ns 

10B 7 

ECS, OCS Width Negated 

5 

— 

5 

— 

ns 

11 

FC, Size, RMC, CIOUT, Address Valid to AS Asserted 
land DS Asserted, Read) 

5 


5 


ns 


IPEND to AS Asserted (and DS Asserted, Read) 

5 

... 

-1 

... 

ns 

12 

Clock Low to AS, DS, CBREQ Negated 

0 

10 

0 

15 

ns 

12A 

Clock Low to ECS/OCS Negated 

0 

15 

0 

16 

ns 








13 

AS, DS Negated to FC, Size, RMC, CIOUT, Address 
Invalid 

5 

— 

5 

... 

ns 

14 

AS (and DS, Read) Width Asserted (Asynchronous 
Cycle) 

45 

... 

43 

... 

ns 

14 A 11 

DS Width Asserted, Write 

23 

... 

21 

... 

ns 

14B 

AS (and DS Read) Width Asserted (Synchronous 

Cycle) 

23 

... 

21 

... 

ns 
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13.6 AC ELECTRICAL SPECIFICATIONS - READ AND WRITE CYCLES (Cont’d) 


(Vcc = 5.0 Vdc +/- 5%; GND = 0 Vdc; TA = 0° to 70° C) 


Num 

Characteristic 

33.33 MHz 15 

HP 64430 

Unit 

Min 

Max 

Min 

Max 

15 

AS, DS Width Negated 

23 

... 

21 

... 

ns 

> 

00 

DS Negated to AS Asserted 

18 

... 

18 

— 

ns 

16 

Clock High to AS, DS, R/W, DBEN, CBREQ High 
Impedance 

... 

30 

... 

30 

ns 

17 

AS, DS Negated to R/W Invalid 

5 

... 

3 

... 

ns 

18 

Clock High to R/W High 

0 

15 

0 

15 

ns 

20 

Clock High to R/W Low 

0 

15 

0 

15 

ns 

21 6 

R/W High to AS Asserted 

5 

... 

5 

n 

ns 

22 6 

R/W Low to DS Asserted (Write) 

35 

H 


... 

ns 

23 

Clock High to Data Out Valid 

... 

D 

— 

19 

ns 

24 

Data Out Valid to Negating Edge of AS 


■ 

3 

— 

ns 

25 6 ' 11 

AS, DS Negated to Data Out Invalid 



5 

■ 

ns 

25A 9 ’ 11 

DS Negated to DBEN Negated (Write) 

5 

... 

5 

... 

ns 

26 611 

Data Out Valid to DS Asserted (Write) 

5 

... 

5 

... 

ns 

27 

Data-In Valid to Clock Low (Synchronous Setup) 

i 

... 

6 

... 

ns 

21A 

Late BERR, HALT Asserted to Clock Low (Setup) 

3 

... 

10 

... 

ns 
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13.6 AC ELECTRICAL SPECIFICATIONS - READ AND WRITE CYCLES (Cont’d) 
(Vcc = 5.0 Vdc +/- 5%; GND = 0 Vdc; TA = 0° to 70° C) 


Num 

Characteristic 

33.33 MHz 15 

Min Max 

HP 64430 

Min Max 

Unit 








28 12 

AS, DS Negated to DSACKx, BERR, HALT, AVEC 
Negated (Asynchronous Hold) 

0 

30 

0 

18 

ns 

28A 12 

Clock Low to DSACKx, BERR, HALT, AVEC 

Negated (Synchronous Hold) 

6 

50 

6 

43 

ns 

29 12 

DS Negated to Data-In Invalid (Asynchronous Hold) 

0 

—- 

0 

... 

ns 

29A 12 

DS Negated to Data-In High Impedance 

— 

30 

... 

27 

ns 

30 12 

Clock Low to Data-In Invalid (Synchronous Hold) 

6 

... 

6 


ns 

30A 12 

Clock Low to Data-In High Impedance (Read followed 
by Write) 

... 

45 

— 

35 

ns 

31 2 

DSACKx Asserted to Data-In Valid (Asynchronous 

Data Setup) 

... 

20 

... 

20 

ns 

31 A 3 

DSACKx Asserted to DSACKx Valid (Skew) 

— 

5 

— 

5 

ns 

32 

RESET Input Transition Time 

— 

1.5 

— 

1.5 

Clks 

33 

Clock Low to BG Asserted 

0 

15 

0 

24 

ns 

34 

Clock Low to BG Negated 

0 

15 

0 

24 

ns 

35 

BR Asserted to BG Asserted (RMC Not Asserted) 

1.5 

3.5 

1.5 

3.5 

Clks 

37 

BGACK Asserted to BG Negated 

1.5 

3.5 

1.5 

3.5 

Clks 

37A 

BGACK Asserted to BR Negated 

0 

1.5 

0 

1.5 

Clks 
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13.6 AC ELECTRICAL SPECIFICATIONS - READ AND WRITE CYCLES (Cont’d) 
(Vcc = 5.0 Vdc +/- 5%; GND = 0 Vdc; TA = 0° to 70° C) 


Num Characteristic 

39 6 BG Width Negated 
39A BG Width Asserted 

40 Clock High to DBEN Asserted (Read) 

41 Clock Low to DBEN Negated (Read) 

42 Clock Low to DBEN Asserted (Write) 

43 Clock High to DBEN Negated (Write) 

44 R/W Low to DBEN Asserted (Write) 


45 s DBEN Width Asserted (Asynchronous Read) 

DBEN Width Asserted (Asynchronous Write) 

45 9 DBEN Width Asserted (Synchronous Read) 

DBEN Width Asserted (Synchronous Write) 

46 R/W Width Asserted (Asynchronous Write or Read) 


46A R/W Width Asserted (Synchronous Write or Read) 


47A Asynchro nous Input Setup Time (HALT, BERR, 

DSACKx) _ 

Asynchronous Input Setup Time (IPLx) 


Asynchronous Input Hold Time from Clock Low 


DSACKx Asserted to BERR, HALT Asserted 


53 Data Out Hold from Clock High 


33.33 MHz HP 64430 


Min 

Max 

Min 

Max 

Unit 

45 

... 

43 

... 

ns 

45 

... 

43 

... 

ns 

0 

18 

0 

19 

ns 

0 

18 

0 

19 

ns 

0 

18 

0 

19 

ns 

0 

18 

0 

19 

ns 

5 


5 


ns 
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13.6 AC ELECTRICAL SPECIFICATIONS - READ AND WRITE CYCLES (Cont’d) 


(Vcc = 5.0 Vdc +/- 5%; GND = 0 Vdc; TA = 0° to 70° C) 


Num 

Characteristic 

33.33 MHz 15 

HP 64430 

Unit 

Min 

Max 

Min 

Max 

55 

R/W Asserted to Data Bus Impedance Change 

15 

--- 

12 

--- 

ns 

56 

RESET Pulse Width (Reset Instruction) 

512 

--- 

512 

--- 

Clks 

57 

BERR Negated to HALT Negated (Rerun) 

0 

--- 

2 

--- 

ns 

58 10 

BGACK Negated to Bus Driven 

1 

--- 

1 

--- 

Clks 

59 10 

BG Negated to Bus Driven 

1 

--- 

1 

--- 

Clks 

60 13 

Synchronous Input Valid to Clock High (Setup Time) 

2 

--- 

4 

--- 

ns 

61 13 

Clock High to Synchronous Input Invalid (Hold Time) 

6 

--- 

6 

--- 

ns 

62 

Clock Low to STATUS, REFILL Asserted 

0 

15 

0 

25 

ns 

63 

Clock Low to STATUS, REFILL Negated 

0 

15 

0 

25 

ns 


MC68030 electrical specifications reprinted courtesy Motorola, Inc. 

NOTES: 


1. This number can be reduced to 5 nanoseconds if strobes have equal loads. 


2. If the asynchronou s setup tim e (#4 7A) req uirements are satisfied, the DSACKx low to data 
setup time (#31) and DSACKx low to BERR low setup time (#48) can be ignored. T he data must 
only satisfy the data -in to c lock low setup time (#27) for the following clock cycle and BERR must 
only satisfy the late BERR low to clock low setup time (#27A) for the following clock cycle. 


3. This param e ter specifie s the maximum allowable skew between DS ACKO to D S ACK1 asse rted 
or DSACK1 to DSACKO asserted; specification #47A must be met by DSACKO or DSACK1. 
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4. This specification applies to the first DSACKx signal asserted. In the absence of DSACKx, 
BERR is an asynchronous input using the asynchronous input setup time (#47A). 


5. DBEN may stay asserted on consecutive write cycles. 

6. The minimum values must be met to guarantee proper operation. If this maximum value is 
exceeded, BG may be reasserted. 


7. This specification indicates the minimum high time for ECS and OCS in the event of an internal 
cache hit followed immediately by a cache miss or operand cycle. 

8. This specification guarantees operation with the MC68881/MC68882, which specifies a minimum 
time for DS negated to AS asserted (specification #13A in the Motorola MC68881/MC68882 User’s 
Manual). Without this specification, incorrect interpretation of specifications #9A and #15 would 
indicate that the MC68030 does not meet the MC68881/MC68882 requirements. 

9. This specification allows a system designer to guarantee data ho ld times on the output s ide of 
data buffers that have output enable signals generated with DBEN. The timing on DBEN precludes 
its use for synchronous read cycles with no wait states. 

10. These specifications allow system designers to guarantee that an alternate bus master has 
stopped driving the bus when the MC68030 regains control of the bus after an arbitration sequence. 

11. DS will not be asserted for synchronous write cycles with no wait states. 

12. These hold times are specified with respect to strobes (asynchronous) and with respect to the 
clock (synchronous). The designer is free to use either hold time. 

13. Synchronous inputs must meet specifications #60 and #61 with stable logic levels for all rising 
edges of the clock. These values are specified relative to the high level of the rising clock edge. 

14. This specification allows system designers to qualify the CS signal of an MC68881/MC68882 
with AS (allowing 7ns for a gate delay) and still meet the CS to DS setup time requirement 
(specification 8B) of the MC68881/MC68882. 

15. The clock signal used during test has 5ns of rise time and 5ns of fall time. For system 
implementations that have less clock rise and fall times, the clock pulse width minimum should be 
commensurately longer so that: system (t 2 +(t 4 +ts/ 2 )) is = or greater than minimum ti/2 and system 
(t 3 +(t 4 -H 5 / 2 )) is = or greater than minimum ti/2. 
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HP 64430 DC Electrical Specifications 


(Vcc = 5.0 Vdc +/- 5%; GND = 0 Vdc; T A = 0° to 70° C) 


Characteristic 

Symbol 

Min 

Max 

Unit 

Input High Voltage 

VlH 

2.0 

Vcc 

V 

Input Low Voltage 

VlL 

-0.5 

0.8 

V 

Input Leakage 

BR, BGACK, IPLx, MMUDIS, CDIS, 

Iin 

-2.5 

2.5 

uA 

Current 






GND = or < Vin = 






or < VCC 






Input High Current 

CBACK, CIIN, STERM 

IlH 

_ 

0 

uA 


BERR, AVEC, DSACKx, HALT 


--- 

25 



CLK, RESET 


... 

50 


Input Low Current 

RESET, CBACK, CIIN, STERM 

IlL 

__ 

-1.4 

mA 


CLK, BERR, AVEC, DSACKx, HALT 


... 

-0.25 


Output High Voltage 

A0-A31, AS, BG, D0-D31, DBEN, DS, ECS, 

VoH 

2.4 

_ 

V 

Ioh = -400uA 

RAV, STATUS, REFILL, IPEND, OCS, 






RMC, SIZ0-SIZ1, FC0-FC2, CBREQ, CIOUT 





Output Low Voltage 


VOL 



V 

Iol = 2.5mA 

A0-A31, FC0-FC2, SIZ0-SIZ1 


— 

0.5 


Iol = 3.2 mA 

BG, D0-D31 


--- 

0.5 


Iol = 4.5mA 

CBREQ, RAV, RMC 



0.5 


Iol — 5.3 mA 

AS, DS, DBEN, IPEND 


--- 

0.5 


Iol = 2.0 mA 

STATUS, REFILL, CIOUT, ECS, OCS 


... 

0.5 


Iol = 9.3 mA 

RESET 


... 

0.5 


Power Dissipation 

Ta = 0° C 

Pd 

_ 

0 

W 


Ta = 70° C 


... 

0 


Capacitance (Vin = 0V, Ta = 25° C, f = 1MHz) 

Cin 

... 

20 

pF 

Load Capacitance 


C L 

— 

100 

pF 




... 

50 
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Notes 
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Index 


! .EA configuration file ,2-13 

.EA file ,6-29 

.EB configuration files ,2-13 

A absolute files, loading ,6-27 

accessing the emulation system ,3-9 
address range overlays ,4-29 
address specification, custom register ,8-4 
address translation cache (ATC), flushing ,5-3 
analysis with cache enabled ,6-15 
analyzer ,6-29 - 6-30 

analyzer, debugging plug-in failures ,6-30 

analyzer, use for debugging ,6-30 

are you there function, how it works ,10-3 

B background ,1-5 

background monitor ,7-3 

background monitor, defaulting stack pointer for ,4-14 
BERR, enabling/disabling ,6-19 
block size ,4-28 

blocking target BERR during emulation memory cycles ,4-25 

break function, breaking into the monitor ,7-6 

break on write to ROM ,1-3 

breakpoints ,1-4 

bus cycle ,6-30 

bus cycle, none for more than 250 milliseconds ,6-30 
bus size bit (B) ,6-30 

C cache control ,6-14 
caches, using the ,6-14 
card cage access cover, removing the ,2-6 
clock rates, CPU ,4-47 
code branches, incorrect ,6-30 
command modules, emulation monitor ,7-10 
command scanner ,7-9 

comparison of foreground/background monitors ,7-3 
compiling the demonstration programs ,3-8 


Index-1 


configuration file name ,4-51 

configuration file, .EA ,2-13 

configuration file, .EB ,2-13 

configuration file, starting with the default ,6-29 

configuration file, veiwing ,6-29 

configuration file, what to do after modifying ,2-13 

configuration file,incorrect ,6-29 

configuration, deMMUer ,4-41 

configuration, review ,6-29 

configuring simulated I/O ,9-2 

connecting the emulator pod to your target system ,2-10 
continuing target system interrupts 
while in the emulation monitor ,7-18 
controlling flow of data and code ,4-26 
coprocessor configuration questions ,8-13 
coprocessor copy routine ,8-11 
coprocessor register buffer, emulation monitor ,8-9 
copying from target memory, how it works ,10-16 
copying the demonstration programs to your subdirectory ,3-7 
copying to target system memory, how it works ,10-17 
CPU clock rates faster than 25 MHz ,4-47 
cpu registers, modifying, how it works ,10-19 
custom coprocessor, register set display specification ,8-5 
custom coprocessors support ,1-5 
custom coprocessors, modifying configuration for ,4-20 
custom register address specification ,8-4 
custom register format file ,8-3 
custom register format file, specifying ,4-22 
custom register name specification ,8-4 
custom register size specification ,8-4 
custom registers, emulation monitor changes ,8-9 
customizing the emulation monitor ,7-12 

D debugging plug-in failures with analyzer ,6-30 
debugging plug-in problems ,6-29 
debugging, use status messages ,6-30 
default response to emulation configuration questions ,4-3 
defaulting stack pointer for background monitor ,4-14 
deleting memory map entries ,4-41 


2-Index 



deMMUer ,1-4 

addresses for which it has no translation ,5-3 
how it operates ,5-2 

how to access the deMMUer configuration display ,5-10 

how to turn off ,5-7 

how to turn on ,5-7 

startup with the emulator ,5-6 

turn on/off by setting the analysis mode ,5-8 

turn on/off using emulation configuration questions ,5-7 

what it is ,5-2 

when it will not do reverse-address translations ,5-5 
when to start ,5-6 
when to turn off ,5-5 
when to use ,5-4 
deMMUer configuration ,4-41 
displaying cpu registers, how it works ,10-18 
displaying global symbols ,3-12 
displaying local symbols, example ,3-13 
displaying memory ,3-14 
displaying registers ,3-17 
displaying target memory, how it works ,10-15 
dividing the processor address space ,4-26 
DMA enable/disable ,6-19 
dma transfers into emulation memory ,4-46 
dma transfers, enabling ,4-45 
DSACK and STERM, interlocking 
emulation memory and target ,6-10 
dsack DSACK signal problems, open 
collector drivers on DSACK line ,6-11 
DSACK signal problems, early removal of DSACK signals ,6-12 
DSACK signal problems, isolating the problem ,6-12 
DSACK signal problems, target system ,6-11 
DSACK signals, using ,6-10 

E emulation configuration, modifying the default ,3-9 
emulation features 

custom coprocessors support ,1-5 
foreground or background mmonitor ,1-5 
function codes ,1-5 
memory management ,1-4 
oui-of-circuit or in-circuit emulation ,1-6 
emulation memory ,4-29 


Index-3 



emulation memory breakpoints with cache enabled ,6-16 
emulation memory display operations ,4-29 
emulation memory load operations ,4-29 
emulation memory, loading ,3-11 
emulation monitor 

foreground or background ,1-5 
monitor ,1-5 

emulation monitor changes for custom coprocessors ,8-9 
emulation monitor description ,7-7 
emulation monitor entry point routines ,7-8 
emulation monitor functions, enabling ,4-6 
emulation monitor memory requirements ,4-29 
emulation monitor, coprocessor register buffer ,8-9 
emulation monitor, loading ,6-24, 7-22 
emulation pod configuration, modifying ,4-43 
emulation system components, example system ,3-2 
emulation system hardware, installing ,2-5 
emulation system, accessing ,3-9 
emulation system, preparing ,3-8 
emulator 
purpose ,1-2 
emulator features 
breakpoints ,1-4 
processor reset control ,1-4 
register display/modify ,1-4 
restrict to real-time runs ,1-2 
single-step processor ,1-4 

emulator pod cables, connecting to the emulator boards ,2-7 

emulator pod, connecting to the target system ,2-10 

emulator use of int7,enabling ,4-9 

emulator use of software breakpoints, enabling ,4-12 

enabling the foreground monitor ,4-18 

ending the emulation session ,3-34 

ending the mapping session ,4-42 

entering mapper blocks ,4-30 

entering mapper blocks, syntax ,4-30 

entry point routines, emulation monitor ,7-8 

error messages ,A-1 

examples, emulation system used for ,3-2 
exception vector table ,7-7 

EXCEPTION_ENTRY emulation monitor routine ,7-9 



executing a software breakpoint, how it works ,10-8 
external hardware features of the instrumentation cardcage ,2-1 

F failures, plug-in ,6-29 

flush the address translation cache ,5-3 
foreground ,1-5 
foreground monitor ,7-3 
foreground monitor, enabling ,4-18 

foreground monitor, interlock or provide termination for ,4-19 
function codes ,1-5 

G getting started, linking modules ,3-6 
guarded memory access ,4-4 

H halt ,6-30 

hardware installation instructions ,2-5 
how does a simulated interrupt function ,9-5 

I i/o operations ,4-29 

illegal conditions ,4-4 

initializing and configuring your measurement system ,3-4 
inspecting the equipment ,2-4 
installing boards into the card cage ,2-8 
installing emulation system hardware ,2-5 
installing hardware, instructions ,2-5 
installing software ,2-13 
installing software updates ,2-13 
instructions on installing hardware ,2-5 
interlock the foreground monitor ,4-19 
interlocking emulation memory DSACK 
and STERM and target DSACK and STERM ,6-10 
ipend, enabling target line during emulator breaks ,4-11 
isolate problems ,6-29 

J JSR_ENTRY emulation monitor routine ,7-9 

L leading zeros ,4-32 

linker listing file, example ,7-21 

linking the emulation foreground monitor ,7-22 

linking the program modules ,3-6 

loading emulation memory ,3-11 

loading the emulation monitor ,6-24,7-22 

logical (virtual) address to physical address translation ,5-2 
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M making a subdirectory for your 68030 project ,3-2 
mapper blocks, syntax for entering ,4-30 
mapping display softkey labels ,4-28 
mapping memory ,4-26 
memory access timing issues ,6-26 
memory default ,4-28 
memory management ,1-4 
memory map definition ,4-28 
memory map display entries ,4-27 
memory map example ,4-34 
memory requirements, emulation monitor ,7-21 
MMU table walks, deMMUer tracking ,5-2 
modify default memory ,4-40 
modify defined_codes ,4-37 
Modify memory configuration? ,4-24, 4-43 
modifying a memory configuration ,4-23 
modifying memory ,3-15 
modifying target memory, how it works ,10-16 
modifying the configuration file ,4-2 
modifying the cpu registers, how it works ,10-19 
modifying the default emulation configuration ,3-9 
modifying the emulation monitor exception vector table ,7-14 
modifying the emulation monitor to use simulated interrupts ,9-11 
modifying the memory map ,4-37 
modifying the MON_ALT_BUFFER table ,8-10 
modifying the MON_ALT_REGISTERS table ,8-11 
monitor (emulation) 
background ,7-3 

comparison of foreground/background ,7-3 
foreground ,7-3 

monitor message routine, example ,7-19 
MONITOR_ENTRY emulation monitor routine ,7-8 
MONITOR_ENTRY, foreground monitor label ,1-4 
msinit ,2-13 

N name specification, custom register ,8-4 
naming the configuration file ,4-51 
NMI ,7-6 

O on-chip cache disabling ,4-48 
operational overview ,3-1 
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P partitioning the processor address space ,4-28 
performance ,6-31 

physical address to logical address translation ,5-2 

plug-in failures ,6-29 

plug-in problems, debugging ,6-29 

pod cable, securing ,2-10 

preinstallation inspection ,2-4 

preparing the emulation system ,3-8 

preparing your program modules, getting started ,3-6 

problems, isolate ,6-29 

purpose of the emulator ,1-2 

R real-time runs ,1-2 

real-time/nonreal-time run mode, selecting ,4-4 
register display/modify ,1-4 

register set display specification, custom coprocessor ,8-5 
removing the development environment card cage access cover ,2-6 
reserved address space, using function codes with ,6-17 
reset control ,1-4 

RESETJZNTRY emulation monitor routine ,7-9 

resetting into the monitor ,4-8, 6-24 

restoring the processor interrupt mask ,7-18 

restrict to real-time runs ,1-2 

restrictions on using simulated I/O ,9-4 

restrictions on using simulated interrupts ,9-10 

run command after a software breakpoint, how it works ,10-8 

run command, how it works ,10-4 

run from ... until command, how it works ,10-5 

run from ... until command, using ,6-22 

run from command, how it works ,10-4 

run until command, how it works ,10-5 

running emulation ,4-2 

running from the transfer address ,3-16 

S safety considerations ,1-1, 2-3 

sample emulation configuration command file ,3-16 
securing the pod cable ,2-10 
sending messages from the user 
program to the emulator display ,7-18 
shutdown ,6-30 
simint.c source file ,B-9 
simulated I/O, configuring ,9-1 - 9-2 
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simulated I/O, restrictions on using ,9-4 
simulated interrupt, how they function ,9-5 
simulated interrupts ,9-5 

simulated interrupts, modifying the monitor to use ,9-11 

simulated interrupts, restrictions on using ,9-10 

single stepping with background monitor, how it works ,10-11 

single stepping with foreground monitor, how it works ,10-10 

single-step processor ,1-4 

size specification, custom register ,8-4 

software breakpoint instruction number selection ,4-12 

software breakpoint, setting ,10-7 

software breakpoints ,1-4,10-7 

software breakpoints, using ,3-24 

stack pointer for background monitor, defaulting ,4-14 

starting address of a block boundary ,4-32 

status conditions, incorrect ,6-30 

status messages, use for debugging ,6-30 

step function, using ,3-19 

STERM signals, using ,6-10 

SWBK ENTRY emulation monitor routine ,7-8 

symbolic debugging ,1-2 

symbols ,1-2 

T table search ,5-3 
target memory ,4-29 

target memory breakpoints with cache enabled ,6-16 
target memory display operations ,4-29 
target memory load operations ,4-29 
target memory transfers, how it works ,10-12 
target memory, copying from, how it works ,10-16 
target memory, modifying, how it works ,10-16 
target system ,1-2 
target system interface ,6-1 

target system memory, copying to, how it works ,10-17 

target system program interrupt ,7-6 

target system, connecting to the emulator pod ,2-10 

terminate the foreground monitor ,4-19 

timing issues, memory access ,6-26 

towers.c source file ,B-2 

tracing processor activity ,3-20 

transfer address, running from ,3-16 

translation tables ,5-3 
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translation, logical (virtual) address to physical address ,5-2 
translation, physical address to logical address ,5-2 
trigger pulse ,6-30 

U unpacking the equipment ,2-4 

using breakpoints with caches enabled ,6-15 

using command files ,3-34 

using simulated i/o, example ,3-27 

using the emulation monitor ,6-24 

using the emulator ,3-11 

using the modify memory map command ,4-37 

V vector base register,use of ,6-13 

W writing coprocessor copy routines ,8-11 
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